Jason Orendorff wrote:
On Wed, Oct 3, 2012 at 9:47 AM, Erik Arvidsson<[email protected]> wrote:
On Wed, Oct 3, 2012 at 3:24 AM, Andreas Rossberg<[email protected]> wrote:
On 3 October 2012 05:38, Brendan Eich<[email protected]> wrote:
Which is more important, iterating over holes (preserved if possible), or
skipping them and therefore spreading array-likes but not iterables?
I, for one, couldn't care less about holes. We shouldn't compromise
any useful feature just for the sake of preserving some array hole
craziness.
Filling in holes with undefined seems like the right thing to do.
People do not depend on holes.
Having Array.prototype.@iterator skip holes is bad because we don't
have the index so we don't know that anything was skipped.
I agree. Firefox currently fills holes in with undefined:
js> var a = [1,,,,2];
js> [...a]
[1, undefined, undefined, undefined, 2]
Of course we'll eventually implement whatever TC39 specifies, and I
don't think it matters *too* much; but I like this behavior because
* the spread syntax just uses the iteration protocol;
This differs from Array.from -- any reason not to fall back on the
array-like protocol (which for missing 'length' iterates no values)?
* it lets developers continue to ignore any holes they might have in
their arrays (that is, it doesn't "squeeze out" the holes, which those
developers might find astonishing--of course if they use .sort() or
.forEach() on that array, they'll be astonished anyway).
I agree -- I'm persuaded we should diverge for-of from forEach. This
lets us unify spread with Array.from (I hope). Anyone object?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
