Le 29/12/2013 00:11, Rick Waldron a écrit :
> On Sat, Dec 28, 2013 at 5:44 PM, Domenic Denicola 
> <domenic at domenicdenicola.com <mailto:domenic at domenicdenicola.com>> wrote:
>
>     I believe that Array.from's only purpose is to provide guidance
>     for polyfills for people to use in ES3/ES5 code; nobody writing
>     ES6 would ever use it.
>
>
> Ignoring any of the previous benefits I've discussed, it seems you're 
> forgetting about the map function feature of Array.from?
Ok, so to re-focus for those following at home, there are 3 cases to 
consider for authors:
1) code only aiming at ES3/5
2) code aiming at both ES3/5 and ES6 environments
3) code only aiming at ES6 envs.

For 1), let's all keep doing what we've been doing. In ES3/5, there is 
not really a notion of iterable protocol as it's not used by the 
language as it is in ES6.
For 3), from an iterable to an array, it takes ``[...iterable]`` IIUC, 
no need for Array.from at all.
2) is the subtle case. There is only one code base. Because it needs to 
work in ES3/5, it can't use @@iterable (like jQuery as Rick stated). 
However, ES6 code may want to iterate over the arraylikes generated by 
the library with for-of and spread. This is where Array.from comes handy 
if it works both for @@iterables and arraylikes.
But an Array._from library could work equally well for this purpose. No 
need for the built-in Array.from to handle arraylikes.

Dominic Denicola:
> I also forgot about how it would be useful for subclasses, e.g. 
> Elements.from(nodeList), since subclasses don't have their own 
> dedicated spread syntax. Withdrawn in full.
Oh... super true. Array.from or perhaps less confusingly "just-from" 
enables to convert any iterable to another iterable (assuming proper 
@@create setup). But that's an ES6-only use case and is unrelated to the 
arraylike handling I think.
Side note: it's somewhat ironic that Array carries 'from' given it's the 
only "class" that doesn't need it per case study for 3) above :-)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131229/b9ef777e/attachment.html>

Le 29/12/2013 00:11, Rick Waldron a écrit :

> Ignoring any of the previous benefits I've discussed, it seems you're 
> forgetting about the map function feature of Array.from?

Ok, so to re-focus for those following at home, there are 3 cases to 
consider for authors:

1. code only aiming at ES3/5
2. code aiming at both ES3/5 and ES6 environments
3. code only aiming at ES6 envs.

For 1), let's all keep doing what we've been doing. In ES3/5, there is 
not really a notion of iterable protocol as it's not used by the 
language as it is in ES6.
For 3), from an iterable to an array, it takes ``[...iterable]`` IIUC, 
no need for Array.from at all.
2) is the subtle case. There is only one code base. Because it needs to 
work in ES3/5, it can't use @@iterable (like jQuery as Rick stated). 
However, ES6 code may want to iterate over the arraylikes generated by 
the library with for-of and spread. This is where Array.from comes handy 
if it works both for @@iterables and arraylikes.
But an Array._from library could work equally well for this purpose. No 
need for the built-in Array.from to handle arraylikes.

Dominic Denicola:
> I also forgot about how it would be useful for subclasses, e.g. 
> Elements.from(nodeList), since subclasses don't have their own 
> dedicated spread syntax. Withdrawn in full.

Oh... super true. Array.from or perhaps less confusingly "just-from" 
enables to convert any iterable to another iterable (assuming proper 
@@create setup). But that's an ES6-only use case and is unrelated to the 
arraylike handling I think.
Side note: it's somewhat ironic that Array carries 'from' given it's the 
only "class" that doesn't need it per case study for 3) above :-)