Why does Array.from accept non-iterable arraylikes?
dean at deanlandolt.com
Wed Jun 26 09:11:54 PDT 2013
On Wed, Jun 26, 2013 at 11:16 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:
> From: Claude Pache
> > implement/polyfill the iteration protocol in both old and new
> environments, using `GetIteratorSymbol()` where @@iterator is needed. If
> that `GetIteratorSymbol()` function is readily available in a standard
> place, it will allow different libraries to cooperate.
> I think this is not necessary for library cooperation or
> forward-compatible polyfilling. It may make it *nicer*, but it's not
> necessary, and I'd predict not even that helpful.
> It's very easy for a community to standardize on a simple property name,
> whether it be `iterator` or `__iterator__`, without needing a blessed one
> handed down from TC39. The polyfill community can probably figure this out
> themselves. I can't see any polyfill maintainers rejecting a pull request
> to switch to a more widely-used name. And I don't think there will be that
> many incompatible polyfill libraries out there anyway; in ES5 at least,
> we've seen one ascendant.
I hope you're right, but I doubt it. At least in this case the language
clearly defines the semantics of the underlying protocol so it *seems
like*polyfills will only have one thing to agree on. But (especially
particularly non-unique key like `iterator` or `__iterator__` is chosen)
they will also have to agree on what it to do when they see something that
doesn't adhere to those semantics, and the space of possibilities is vast.
There will be pain.
`GetIteratorSymbol` or something like it could solve all of this with the a
few flicks of AWB's fingers -- what's not to like?
> As for forward compatibility, this is pretty simple: just use `eval`. Icky
> and annoying, but [it works]. If you detect native iterator support,
> don't polyfill.
That's fine for sniffing for `for/of` support but tells you nothing about
whether you've already been polyfilled, and what else you may need to do.
Iteration polyfills will likely want to shim some or all of the built-in
iterators. So they'll have to go somewhere too, but where?
Does the spec. already give us a way to get at the system modules cleanly
or are we going to have to shim in enough of a dynamic loader to allow our
polyfill-dependent code to "load" them, awkwardly? How will we keep these
loaders from stepping on each other? This is a more important issue than
whether or not the iterator key is a unique symbol, but if there were a
coherent way to polyfill system modules it would solve this problem too.
The iteration key live in @iter -- any polyfills wouldn't have to agree on
what it is, they would just look it up from here. Typical to polyfills, the
first shimmer wins WRT what the filled-in key looks like. Other built-ins
could be tested and filled in a similar fashion. Problem solved.
I apologize if this has been covered already -- is there any plan to expose
the built-in system modules in global space, one way or another? I try to
follow this list closely but I haven't seen much discussion about it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss