Why does Array.from accept non-iterable arraylikes?

Jason Orendorff jason.orendorff at gmail.com
Wed Jun 26 06:38:31 PDT 2013


On Tue, Jun 25, 2013 at 9:36 PM, Brandon Benvie <bbenvie at mozilla.com> wrote:
> 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 most
> of the other extension points, there's some amount of "manually cranking the
> 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
is.

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.

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. for-of is just syntactic
sugar. @@seti, @@geti, @@call, and @@construct are pretty clearly in
another category, at least to me.

> (I also don't think that polyfillability is a good argument here, because as
> I said before, it's possible to create a polyfill that works in ES3-ES6 that
> provides a compatibility layer over iteration.)

Well... I think a pretty strong argument could be made that we on TC39
don't discount the future enough, that we assume the future we can
predict and affect is longer (and the interest rate lower) than it
really is. But I'm not the person to make that argument. I don't have
the temperament for it. Maybe Rick or Tab. :-)

Seriously, I don't make a habit of focusing on the short term and
that's not what I'm doing here.

-j


More information about the es-discuss mailing list