> Le 26 déc. 2013 à 18:20, David Bruant <[email protected]> a écrit : > > Le 26/12/2013 10:58, David Bruant a écrit : >> Le 26/12/2013 05:00, Rick Waldron a écrit : >>> >>> On Wed, Dec 25, 2013 at 7:33 PM, David Bruant >>> >>>> For the rationale, the wiki states [1]: >>>> "There are many array-like objects in JS (arguments objects, DOM >>>> NodeLists, arrays from separate windows, typed arrays) and no simple way >>>> to convert one of these to an instance of Array in the current window; >>>> this is the rationale behind a simple conversion function (Array.from)." >>>> >>>> I think that if all of these objects had a good default @@iterable, there >>>> wouldn't be a need for the array-like part of Array.from. >>>> The "good default" most likely being based on .length, etc. >>> >>> The array-like part is for all of those objects that _won't_ have an >>> @@iterator, for one reason or another >> I must have missed these reasons. No @@iterator also means these objects >> cannot be iterated with via for-of loops by default and I can't think of a >> good reason for that for any of the listed (arguments, NodeList, arrays from >> different windows, typed arrays). >> Do you have a link to previous discussions on this topic or a summary if >> that can be explained quickly? > Found the relevant part of the notes [1]: > "BE: Let's not remain slaves to legacy, Array.from, for-of and spread use > only iterable. > > RW: What about pre ES6 environment? > > BE: Can fall back to array-like if needs." > > I guess this is where I differ as I don't see a need. In ES5 environments, > the default @@iterator can be embedded in Array.from, leading to something > like (worst case for explanatory purposes): > > ````js > Array.from = function(x){ > if(/*x is a NodeList*/){ > // polyfill default NodeList[@@iterator] behavior to create the array > to return > } > if(/*x is an Arguments*/){ > // polyfill default Arguments[@@iterator] behavior to create the > array to return > } > // ... > } > ```` > > Most likely all of these @@iterator polyfills are the same array-like > traversals, so there shouldn't be a need to separate each case, they most > likely all use the same logic. > > Rick Waldron: >> The array-like part is for all of those objects that _won't_ have an >> @@iterator, for one reason or another > The Conclusion/Resolution section of [1] suggests: "Add iterator protocol to > arguments object (should exist on all things." > I went quickly through all the meeting notes I could find and didn't find > something about some objects not having an @@iterator. > > David > > [1] > https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#revisit-nov-27-resolution-on-iterables-in-spread >
There is still the issue of potential libraries that produce arraylikes that don't inherit from a built-in arraylike prototype: those won't benefit from your polyfill without changing their inheritance strategy. (I don't know whether it's a common issue.) —Claude
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
