Why does Array.from accept non-iterable arraylikes?

Dean Landolt dean at deanlandolt.com
Thu Jun 27 11:04:14 PDT 2013


On Thu, Jun 27, 2013 at 11:56 AM, Jason Orendorff <jason.orendorff at gmail.com
> wrote:

> On Wed, Jun 26, 2013 at 7:54 PM, Dean Landolt <dean at deanlandolt.com>
> wrote:
> > On Wed, Jun 26, 2013 at 6:10 PM, Jason Orendorff <
> jason.orendorff at gmail.com>
> > wrote:
> >> > 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?
>
> I think I disagree, but I'm afraid I don't fully appreciate your point yet.
>
> If you mean a library function that expects either an iterable or a
> dictionary, then it would correctly treat your non-iterable data
> object as a dictionary. So... I guess I don't see the problem.
> Everything seems fine.
>
> Surely "length" is a more common database column name than "iterator".
> So if you're right, surely we already have these problems with
> existing library functions that take arraylike objects. Is that the
> case? Are there confusing bug reports and hacked-in fallbacks?
>

Apples and oranges -- people don't use arrays as maps. I've seen countless
cases where object keys . Perhaps a better example would be
`hasOwnProperty` -- I know there have been bug reports. The MDN page goes
out of its way to warn about this [1]:

JavaScript does not protect the property name hasOwnProperty; thus, if the
possibility exists that an object might have a property with this name, it
is necessary to use an *external* hasOwnProperty to get correct results ...

That's right -- MDN goes out of its way to recommend
`Object.prototype.hasOwnProperty.call`. This is *exactly* what I fear. It's
not a huge loss for hasOwnProperty (or toString) -- experienced JS devs
just accept the fact that polymorphism can't be counted on for these
properties. It would be tragic for this fate to befall `iterator`
polymorphism. In part because it's unnecessary, but also because
polymorphism is central to iterator's usefulness (which I know you agree
about, otherwise you wouldn't be arguing so forcefully against symbol-based
keys).

[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130627/b9532d9c/attachment.html>


More information about the es-discuss mailing list