Why does Array.from accept non-iterable arraylikes?

Dean Landolt dean at deanlandolt.com
Fri Jun 28 10:28:06 PDT 2013


On Fri, Jun 28, 2013 at 9:59 AM, Jason Orendorff
<jason.orendorff at gmail.com>wrote:

> On Thu, Jun 27, 2013 at 1:04 PM, Dean Landolt <dean at deanlandolt.com>
> wrote:
> > On Thu, Jun 27, 2013 at 11:56 AM, Jason Orendorff
> > <jason.orendorff at gmail.com> wrote:
> >> 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.
>
> Dean, I would appreciate a response to this. An example of a specific
> case where there would be an actual problem would help the
> conversation tremendously.
>
> >> 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.
>
> People won't use iterables as maps either; the kind of maps we are
> talking about are ObjectLiterals, and they are not iterable. (You can
> iterate over their properties, though, using a 4-line generator or
> Object.keys().)
>
> The reason I brought up that example is that people *do* use objects
> with .length properties as arraylikes, leading to potential ambiguity
> about whether an object with a .length property is a plain-Object map
> or an arraylike. I thought perhaps that was the sort of confusion you
> were concerned about.
>

You've got bigger problems if you're trying this -- the language defines
semantics for `length` on strings and arrays -- generic code would be
foolish to try and go further. But this example does in fact kill my
argument (see below).

An aside -- yes, in my ideal world there would be a unique symbol that
stood in for the `count` of a thing (how many distinct `items` it has).
More than one, in fact, since there are competing notions of counts on the
same kind of thing. If designed carefully this kind of approach could go a
long way toward cleaning up the notion of types in javascript...but I'm way
off topic...


> > 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]:
>
> This is a problem because .hasOwnProperty is an operation that people
> naturally want to apply to plain-Object maps.
>
> .iterator() is not, because plain Objects are not iterable.
>

I was missing this detail -- I remember the discussion around this but for
some reason was assuming a different design with a default iterator on
Object.prototype, and the built-in iterator methods deferring to this).
Admittedly this weakens my arguments. But I still wonder how the actual
built-in iterators are expected to be shimmed (without shimming a whole
module system)? From this thread I believe *this* is the core problem that
has yet to be addressed. If solved it would also make system symbols much
less inconvenient for polyfills.

>From this perspective it seems unnecessary to, umm, pee in the namespace
pool. But yeah, my strongest arguments for iterator-as-symbol are pretty
well mooted :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130628/06aac9cf/attachment.html>


More information about the es-discuss mailing list