On Wed, Oct 3, 2012 at 2:57 PM, Brendan Eich <[email protected]> wrote:
> Jason Orendorff wrote: > >> On Wed, Oct 3, 2012 at 11:34 AM, Brendan Eich<[email protected]> >> 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
