On Wed, Dec 25, 2013 at 7:33 PM, David Bruant <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
