Why does Array.from accept non-iterable arraylikes?

Dean Landolt dean at deanlandolt.com
Tue Jun 25 11:12:08 PDT 2013


On Tue, Jun 25, 2013 at 1:33 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Jun 25, 2013, at 10:19 AM, Anne van Kesteren wrote:
>
> > On Tue, Jun 25, 2013 at 4:58 PM, Jason Orendorff
> > <jason.orendorff at gmail.com> wrote:
> >> On Tue, Jun 25, 2013 at 10:42 AM, Sam Tobin-Hochstadt <
> samth at ccs.neu.edu> wrote:
> >>> My recollection is that we chose to make `iterator` a symbol because
> >>> we worried about taking the name "iterator" on lots of existing
> >>> objects.
> >>
> >> What kind of existing code would be a problem?
> >>
> >> Firefox added Array.prototype.iterator a year ago. It has shipped in
> >> the release browser, and it's been fine.
> >
> > E.g. HTMLCollection has named getters. Making it iterable without
> > breaking compatibility would be great.
> >
>
> 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.
>
> We could make an exception for iterator, but why?  That just introduces an
> inconsistency in the design.
>


For properties that are expected to be looked up on object or its prototype
unique symbols are the only way to go. Otherwise library code will end up
littered with the `Class.prototype.method.call` pattern and we'll quickly
lose the ability to coherently overload these methods anyway.

But there's still a huge win to be had in *also* defining hooks for this
kind of functionality as static class methods on the built-ins, at least
for the functionality that could otherwise be polyfilled correctly. Any
functionality defined in this way will be instantly usable on the open web
as soon as it gets the TC39 stamp of approval in Rick's meeting notes.
That's a pretty big win for a very small amount of bloat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130625/308fc31c/attachment.html>


More information about the es-discuss mailing list