Suggestions for Set

Brendan Eich brendan at mozilla.com
Wed Oct 3 09:34:20 PDT 2012


Jason Orendorff wrote:
> On Wed, Oct 3, 2012 at 9:47 AM, Erik Arvidsson<erik.arvidsson at gmail.com>  wrote:
>> On Wed, Oct 3, 2012 at 3:24 AM, Andreas Rossberg<rossberg at google.com>  wrote:
>>> On 3 October 2012 05:38, Brendan Eich<brendan at mozilla.com>  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. at 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


More information about the es-discuss mailing list