On Wed, Dec 25, 2013 at 7:33 PM, David Bruant <bruant.d at gmail.com> wrote:

> Hi,
>
> I was reading the current spec for Array.from and it felt too complicated
> to me.


I've been following the specification of Array.from very closely since the
day Dave and I first designed it and it's exactly as complicated as it
needs to be for what it needs to be able to do.



> Currently, at a high-level it reads like:
> 1) if the argument is iterable (@@iterable symbol), create a fresh array
> made of the values iterated on with the iterator
> 2) (step9) if the object is array-like, len = [[Get]] ('length') and from
> 0 to len-1, copy the values of the array-like in a fresh array to be
> returned.
>
> Note that between the two parts, a good share of spec is duplicated.
>
> 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, and for useful shimming in ES5
runtimes. Array.from can be implemented today for array-likes without
Symbols + @@iterator and the same code using Array.from will work correctly
with the built-in Array.from once those `if (typeof Array.from ===
"undefined") {...` check evaluate to false.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131225/e1196532/attachment.html>

On Wed, Dec 25, 2013 at 7:33 PM, David Bruant <bruant.d at gmail.com> wrote:

> I was reading the current spec for `Array.from` and it felt too complicated
> to me.


I've been following the specification of `Array.from` very closely since the
day Dave and I first designed it and it's exactly as complicated as it
needs to be for what it needs to be able to do.



> 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, and for useful shimming in ES5
runtimes. `Array.from` can be implemented today for array-likes without
Symbols + `@@iterator` and the same code using `Array.from` will work correctly
with the built-in `Array.from` once those `if (typeof Array.from === "undefined") {...` check evaluate to `false`.