Suggestions for Set

Rick Waldron waldron.rick at gmail.com
Wed Oct 3 12:50:17 PDT 2012


On Wed, Oct 3, 2012 at 2:57 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Jason Orendorff wrote:
>
>> On Wed, Oct 3, 2012 at 11:34 AM, Brendan Eich<brendan at mozilla.com>
>>  wrote:
>>
>>> * 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)?
>>>
>>
>> I think ES6 should have a single how-to-iterate behavior shared by
>> Array.from, spread syntax, and for-of.
>>
>> Whether that includes a fallback to .length or not seems less important
>> to me.
>>
>> It seems simpler *not* to include the fallback. Firefox doesn't
>> include it at present. Instead, arraylike objects are pretty much all
>> iterable. That wasn't hard to do, since our Array.prototype.iterator
>> is generic.
>>
>
> I buy it.
>
> Not sure why we didn't do it in the July meeting where we settled on
> Array.from testing iterable and falling back on array-like. Perhaps fear
> that @iterator customizations will be missing from a number of array-likes.
>

I didn't realize that existing built-ins and DOM APIs would be modified to
implement the iterator protocol.

One of the reasons we decided to make spread, rest and destructuring
"array-like" only was to limit the surprise factor that would occur with
sparse arrays. The behaviour we wanted to avoid is present in Firefox 18

var a = new Array(10);

// A
console.log( a.map(function() { return 1; }) ); // [, , , , , , , , , ,]
// B
console.log( [...a].map(function() { return 1; }) ); // [1, 1, 1, 1, 1, 1,
1, 1, 1, 1]


>From the notes:

Destructing and spread - no iterator protocol.
(return to existing draft semantics of arraylike — [Cannot be both iterable
and array-like])


I believe this was referring to iterator protocol filling in the holes
with undefined, creating an unexpected result, therefore something
cannot be both iterable and array-like without surprises. The result
of calling Array.isArray(a) and Array.isArray([...a]) will be be true,
but one appears to be constructed differently then the other.

Changing A to work like B could very well break things; but like Erik,
Andreas and I have said above, holes are a myth in real-world code.

At one point I believed I had a valid use case, but it turned out that
it was better to manually fill in with undefined.



Rick


> On that point, does NodeList have an iterator in Firefox now? That's an
> obvious Array.from argument





> type.
>
> /be
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121003/9347d2c3/attachment.html>


More information about the es-discuss mailing list