Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse the current signature of Deno.copy #3422

Closed
tunnckoCore opened this issue Nov 30, 2019 · 6 comments
Closed

Reverse the current signature of Deno.copy #3422

tunnckoCore opened this issue Nov 30, 2019 · 6 comments

Comments

@tunnckoCore
Copy link

As seen here https://twitter.com/tunnckoCore/status/1200346772893323264

Currently copy signature is dst, src which totally deviates from the standard one which is used in the rest of the API - copyFile, readFile, writeFile are all src, dest.

And more or less the API is already following the years of experience in Node.js and is more or less similar thing. There's no copy in Nodejs and that's the only thing that is different in Deno. For me, it doesn't make sense to randomly follow some other language signature and more so one single method of a whole API.

@kevinkassimo
Copy link
Contributor

Hmm I wouldn't include writeFile as an example since it is also technically specifying dst (filename) before src (Uint8Array).

I am personally okay with either ordering.

I do want to point out that some actually argue the reason for Unix-y dst, src argument pair is the mindset of dst = src (assignment) <--> copy(dst, src)

For references of fixing the order, Rust did the switch and had an interesting discussion here and related discussion

@tunnckoCore
Copy link
Author

Ah, actually, yeah - correct.

I can see why copy can and is following the underlying language API. But at least we should take the fact that's it's more intuitive and more natural to say "copy this to that", where this is src and that is dest - just like cp and mv.

Seeing such decisions not for the first time, I never understood why things like Deno (tools, languages and etc) that are based on something should partly inherit the lower-level. Even more in the case of Deno, where the ecosystem and community has nothing to do with Go or Rust - meaning that Deno is oriented to javascript/nodejs/typescript/web developers which may not be (and it's not required to be) familiar with such langs. Deno is providing familiar Web/nodejs/browser APIs. What if we have move? If we follow the current logic it will have dst, src signature too?

Hypothetically, It's like as package author (in nodejs realm) to export readFileAsync and readFile (sync) instead readFile and readFileSync just for the sake to be different and mess with consumer's minds.

@ry
Copy link
Member

ry commented Nov 30, 2019

@tunnckoCore Much of Deno's internal code is ported from Go, including this copy function. The ordering of arguments is intentional - it's like strcpy in C.

@ry ry closed this as completed Nov 30, 2019
@tunnckoCore
Copy link
Author

tunnckoCore commented Nov 30, 2019

Yea, okay. But why web developers should accept something inherited from lower-level bases and write in a way that's not aligned to some logical, natural & intuitive way? Okay, they will, and most probably won't care why it's that way, and learn it and write it that way, but...

And yea, okay, it's probably a bit religious thing. I'm in programming for a decade and I just don't getting why this is done. The logical sense and natural way of thinking while writing it is that you're copying A to B, and you're kind of supposed to write it in the same way/direction copy(src,to dest). If it's reversed it will mess up with every single human/developer, except those that are skilled and know the reasons and what's happening under the hood.

I'm always about the little things and details. They some times can drive me crazy and I'm sure I'm not the only one.

@ry
Copy link
Member

ry commented Apr 24, 2020

I was overruled in this. We are changing the order of copy's args

#4885

@tunnckoCore
Copy link
Author

Awesome! <3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants