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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131226/713f9816/attachment-0001.html>

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 [the notes][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`.

[1]: https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#revisit