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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
