Why does Array.from accept non-iterable arraylikes?

Dean Landolt dean at deanlandolt.com
Wed Jun 26 17:54:07 PDT 2013


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

> On Wed, Jun 26, 2013 at 12:15 PM, Dean Landolt <dean at deanlandolt.com>
> wrote:
> > On Wed, Jun 26, 2013 at 12:15 PM, Jason Orendorff
> > <jason.orendorff at gmail.com> wrote:
> >> 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.
>
> If the test returns false, then the object is not iterable.
>
> > 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? [...]
>
> Well, no, it should be treated like any other non-iterable object.
>


Oh? I know I've personally created boolean database columns named
"iterator" -- I'm sure I'm not alone. I pity the poor ORM user that tries
to pass their objects to a library function which tries to iterate without
fallback. Of course we know what's going to happen -- confusing bug reports
will pressure library authors to hack in fallbacks, or just skip the
unstratified iterator call entirely. Do you disagree? How else do you see
libraries handling this specific case?

Spelling it `iterator` will *work*, but at what cost? The value of the
protocol is seriously diminished.



> If JS were being designed green-field today, maybe some of us would
> make array.length a symbol, not because it's "meta" (meaning, it is
> used by some key builtins, notably including Function.prototype.apply)
> and not because programmers might want to write a function that
> accepts an argument that's either an arraylike object or a dictionary.
> Those cases *do* exist, but it's just not a problem. Making .length a
> symbol would be a mistake.
>


I disagree that it would be an obvious mistake. Perhaps without syntax help
from the language it would. But if there were a convenient syntax to
reference system symbols like these it would be objectively better as a
symbol. But we're not green-fielding javascript, so any
`Array.prototype.length` comparison is nonsensical.

Just because you assert this isn't a problem doesn't make it so. What
you're suggesting cripples the polymorphism win for no particularly good
reason, and for what? To avoid defining some kind of mapping between system
modules and the pre-es6 primordials? I contend that this mapping is
inevitable...

If I have it right the crux of your argument is that using a string key
makes this feature more polyfillable, but where do you propose polyfills
put the iterators from the @iter module? I'm confident that one or more of
of the polyfills will invent some kind of mapping. Can you already hear the
calls for an ad hoc standard? Ugh. Let's end the madness before it starts
and carve out a place for the system modules in the global namespace. I can
imagine a bunch of ways to do this -- but I don't care much about how it
happens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130626/c7f02b1e/attachment-0001.html>


More information about the es-discuss mailing list