Why does Array.from accept non-iterable arraylikes?

Dean Landolt dean at deanlandolt.com
Wed Jun 26 10:15:48 PDT 2013

On Wed, Jun 26, 2013 at 12:15 PM, Jason Orendorff <jason.orendorff at gmail.com
> wrote:

> On Wed, Jun 26, 2013 at 10:20 AM, Dean Landolt <dean at deanlandolt.com>
> wrote:
> > 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?
> Sure. Polymorphism, therefore a method.
> > 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.
> If we make the name just plain "iterator", there's a conventional
> right answer for this: `typeof obj.iterator === "function"`.

Yes -- my point about the schism is what libraries will decided to do when
that test fails. What if iterator is present but not a function? Do you
walk the prototype chain anyway? Blow up? Punt and lookup an iterator
directly based on a mapping with some type testing? What kind of type
testing? If this is easy to avoid, why *not?*

> See the
> tests for .toString and .valueOf methods in [[ToPrimitive]] (now
> OrdinaryToPrimitive in ES6[1]), the test for a .toJSON method in [2],
> and the test for .then in DOM Promises.[3]

I strongly suspect the language will evolve these into legacy warts, but as
far as I know when these were introduced there weren't bodies of code that
would obviously blow up (except [3] , but I'll get to that), and if they
were, that blood was spilled long ago. I've come across quite a bit of code
that treat objects as maps. Yes, I know we real maps now, and that's great,
but authors of generic library code can't just cross their fingers and hope
downstream users will do the Right Thing. They'll avoid iterators entirely,
or if not, they'll certainly have to skip the `iterator` method lookup if
they want to avoid weird bug reports. That's a fail.

And yes, [3] will be a completely unnecessary mistake if allowed to stand,
and for similar reasons. Assuming the system module could act as a
namespace for branding keys it's completely incomprehensible to my why the
Promises/A+ folks would be unwilling to add an attempted lookup for this
brand as a synonym for `then` to their spec. This is what I'd proposed as
Promises/A++, but nobody seemed terribly interested. But the `then`
ducktest has no place in the web platform -- it's nothing but a hazard. But
that's a rant for another thread.

> If it's a symbol, it appears `obj[iteratorSymbol] !== undefined` is
> what the spec is doing, at least in one place, the test for a
> .@@ToPrimitive method in [1].
>   [1]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.1.1
>   [2]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-15.12.3
>   [3]: http://dom.spec.whatwg.org/#promises-model
> Note that IsCallable(obj) is the same thing as `typeof obj ===
> "function"`. [4], [5]
>   [4]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.2.2
>   [5]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-11.4.3
> Of course existing code on the Web uses every possible flavor of
> type-test, and always will, whether the iterator method name is a
> string, a symbol, or a suffusion of yellow. "Schism" isn't the word.
> "Free-for-all" maybe.

I think you may have missed my point about where the schism is. I hope I've
made it more clear above and in prior posts but to restate: the schism
isn't the ducktest, it's that the ducktest isn't a *quite* a predicate --
sometimes it can fail in a way where you may want to proceed up the
prototype chain (or do something else). This is where I believe there are
interop landmines buried.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130626/0a91edc3/attachment.html>

More information about the es-discuss mailing list