-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Normative: Array Constructor #1331
Comments
I don't know the reasoning, but this has been the behavior for literally decades, and so very likely can't be changed at this point due to web-compat. |
Oh, I can definitely see that being a thing - but I just find it to be so unusual, and with the ramped up development of the specification( the last few years especially ) I thought it was worth bringing to the table as an adjustment. From an outside-in perspective I personally don't know of any issues with the change, after all if From an internal perspective I can definitely see that it might be difficult or impossible to change, or there might just be a good reason for the current setup, but it does seem like an improvement if it is possible, especially with the functionality added from es6 onwards. |
The change would definitely break code, as there is code that relies on It would be interesting to hear the historical rationale from @BrendanEich, or from browser implementors, but I hope it's OK if i close this :-) |
Sure, no problem.
Can I ask what you mean by sparse arrays?
…On Sun, Apr 28, 2019, 12:23 AM Jordan Harband ***@***.***> wrote:
The change would definitely break code, as there is code that relies on
Array(n) producing sparse arrays. Array.from({ length: n }), however,
will produce a dense one.
It would be interesting to hear the historical rationale from @BrendanEich
<https://github.com/BrendanEich>, or from browser implementors, but I
hope it's OK if i close this :-)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1331 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEAT37IMPZOVVQZOGSDWTTLPSUYDNANCNFSM4F3T36MQ>
.
|
https://remysharp.com/2018/06/26/an-adventure-in-sparse-arrays seems like a useful article on the subject. |
Thanks sir!
…On Sat, May 18, 2019, 9:36 PM Jordan Harband ***@***.***> wrote:
https://remysharp.com/2018/06/26/an-adventure-in-sparse-arrays seems like
a useful article on the subject.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1331?email_source=notifications&email_token=AEAT37NE6M2APULYCWHGYNTPWC4KFA5CNFSM4F3T36M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWZRYI#issuecomment-493721825>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEAT37PQDVV7VFPXZ2JOC2DPWC4KFANCNFSM4F3T36MQ>
.
|
There is nothing inherently wrong with the Array Constructor, however, I am curious as to what the rationale is behind only allocating the memory and storing the reference ? It seems like an arbitrary choice ( as far as I know ) to not immediately populate the entirety of the Array with undefined - as that is, the majority of the time in my experience, the intention of the Developer, and a consistent pattern in ECMAScript in general when it comes to variables. This would allow for seamless and immediate use of the functional Array methods (
map
,filter
,reduce
, etc.. ) and would overall improve the Developer experience.As an example of how array works currently:
Array(10); // (10)[ empty x 10 ]
Array(10).map((_,i)=>i); // (10)[ empty x 10 ]
and the workarounds that are most often used:
[...Array(10)]; // (10)[undefined x 10]
[...Array(10)].map((_,i)=>i); // (10) [0,1,2, ... 9]
Array(10).fill(undefined); // (10)[undefined x 10]
Array(10).fill(undefined).map((_,i)=>i*2); // (10)[0,2,4, ... ,18]
Although I classified this under normative - If there wasn't an integral reason for this choice of a simple allocation and reference instead of a populated Array, it seems to me that changing the Array Constructor to accomodate
undefined
intead ofempty
wouldn't lead to any breaking of prior code, and only serve to benefit code concision and clarity.Keep in mind this suggestion may stem from a place of unknown ignorance. I'm not nearly as well-versed in the underlying schematics of ECMAScript as I would like to be, but all the same, I haven't seen another topic devoted to it.
Thanks!
The text was updated successfully, but these errors were encountered: