Why does Array.from accept non-iterable arraylikes?
jason.orendorff at gmail.com
Tue Jun 25 13:09:28 PDT 2013
On Tue, Jun 25, 2013 at 12:33 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> This design discussion really wasn't just about iterator. In ES6 we have various property keys that are hooks deeply into either the semantics of core language features: @@create, @@hasInstance, @@ToPrimitive, @@iterator, @@toStringTag, @@isRegExp.
> Anyone plugging into these hooks really should be intentional about what they are doing. Accidentally doing so my poor name choice may mot be disastrous but it is likely to be dificult to debug. Using a symbol for these properties greatly reduces the likelihood of such an accident.
This is indeed the counterargument. We should weigh this against the
benefits of iterators being polyfillable.
Let's take a concrete example. CKEditor 4 has a constructor named
The full extent of trouble we can expect from this naming conflict is
that if somone accidentally did
arr = Array.from(CKEDITOR.dom);
the error message would say something like "iterator object has no
.next() method" rather than "Object not iterable". The mistake seems
unlikely in the first place, and the resulting error is actually no
harder to debug.
> We could make an exception for iterator, but why? That just introduces an inconsistency in the design.
I think I mentioned several reasons. But mainly, iteration is worth
polyfilling, and making it polyfillable will put it in users' hands
literally years before symbols become universally available.
I don't think the inconsistency will even be all that unaesthetic. ES5
and previous have protocols too, using plain old string property
names: .length, .toString(), .valueOf(), and .prototype. One more is
not so bad, if it's something important.
More information about the es-discuss