Why does Array.from accept non-iterable arraylikes?

Jason Orendorff jason.orendorff at gmail.com
Fri Jun 28 06:59:11 PDT 2013

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

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.

> 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.


More information about the es-discuss mailing list