Why does Array.from accept non-iterable arraylikes?

Jason Orendorff jason.orendorff at gmail.com
Thu Jun 27 08:56:49 PDT 2013


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?

-j


More information about the es-discuss mailing list