Why does Array.from accept non-iterable arraylikes?
jason.orendorff at gmail.com
Wed Jun 26 09:15:12 PDT 2013
On Wed, Jun 26, 2013 at 10:20 AM, Dean Landolt <dean at deanlandolt.com> wrote:
> I assume the primary reason to hang the iterator reference directly off an
> object is so that it can be prototypally overloaded -- would you agree?
Sure. Polymorphism, therefore a method.
> Given that library code tends toward being as generic as possible, I can
> just picture the schism in approaches for looking up the Right iterator.
If we make the name just plain "iterator", there's a conventional
right answer for this: `typeof obj.iterator === "function"`. See the
tests for .toString and .valueOf methods in [[ToPrimitive]] (now
OrdinaryToPrimitive in ES6), the test for a .toJSON method in ,
and the test for .then in DOM Promises.
If it's a symbol, it appears `obj[iteratorSymbol] !== undefined` is
what the spec is doing, at least in one place, the test for a
.@@ToPrimitive method in .
Note that IsCallable(obj) is the same thing as `typeof obj ===
"function"`. , 
Of course existing code on the Web uses every possible flavor of
type-test, and always will, whether the iterator method name is a
string, a symbol, or a suffusion of yellow. "Schism" isn't the word.
More information about the es-discuss