> Le 26 déc. 2013 à 18:20, David Bruant <bruant.d at gmail.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131227/19df0432/attachment.html>

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.)