Why does Array.from accept non-iterable arraylikes?
dean at deanlandolt.com
Wed Jun 26 08:20:49 PDT 2013
On Wed, Jun 26, 2013 at 9:38 AM, Jason Orendorff
<jason.orendorff at gmail.com>wrote:
> On Tue, Jun 25, 2013 at 9:36 PM, Brandon Benvie <bbenvie at mozilla.com>
> > I think that the iteration protocol falls under the type of thing that is
> > better exposed through this layer of faux-stratification rather than
> > completely unstratified, due to its primary use in supporting syntax
> > (for-of). The reason there's any argument against it is because, unlike
> > of the other extension points, there's some amount of "manually cranking
> > wheel" that can be useful with the iteration protocol.
> The main use of the iterable protocol is as a contract between a
> function and its caller: a function may expect an iterable for an
> argument, and the caller has the flexibility of passing a great many
> different things.
> The value of this protocol, and the language features supporting it,
> is determined by how much user code is written to take advantage of
> it. There's a network effect. If everyone uses the iterable protocol,
> it's great. The more objects and APIs don't support it, the worse it
> This means that making the protocol accessible to programmers now
> makes it, and its supporting syntax, much more useful in the future,
> to the degree programmers choose to pre-populate the world with
> iterable objects and APIs that consume them. This is about the end
> state, not the short term.
I completely agree, and would just add that this argument generalizes to
many new es6 features that would be polyfillable *but for...*
> Aside from all that... I get your argument, but I can't help feeling
> that, practically, iterator() is a lot less "meta" and more user-level
> than the other features. It's one thing if a feature hooks into
> property access. iterator() is just a method.
I assume the primary reason to hang the iterator reference directly off an
object is so that it can be prototypally overloaded -- would you agree?
Given that library code tends toward being as generic as possible, I can
just picture the schism in approaches for looking up the Right iterator. It
won't take long before you start seeing branching for typeof iterator !=
'function' (or even deeper feature tests on the iterator return value).
There will be a schism between factions that walk up the prototype chain
applying this same silly logic and those that go strait for their own
iterator. This is inevitable and will create interop headaches *and* make
it harder to count on reliable prototypal overloading of iteration.
This is the crux of my complaint about the plain `iterator` key, and I
don't think it's been addressed yet.
[snipped the rest]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss