Why can't jQuery do
```js
if (typeof Symbol !== "undefined" && Symbol.iterator) {
jQuery.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator];
}
```
________________________________
From: Rick Waldron<mailto:[email protected]>
Sent: 12/28/2013 14:24
To: David Bruant<mailto:[email protected]>
Cc: Brendan Eich<mailto:[email protected]>;
EcmaScript<mailto:[email protected]>
Subject: Re: Overly complicated Array.from?
On Sat, Dec 28, 2013 at 11:37 AM, David Bruant
<[email protected]<mailto:[email protected]>> wrote:
Le 28/12/2013 15:25, Brendan Eich a écrit :
This seems overcomplicated. Isn't the likelier code something like
Array.from || (Array.from = function(b) { var a=[]; for (var i=0; i<b.length;
i++) a.push(b[i]); return a; });
Isn't the whole point to impute arraylikeness to the parameter?
In any case the important point is that it's possible to implement in an ES5
env whatever behavior is expected from Array.from in an ES6 env.
Granted, it's not super elegant solution, but it does work. The overhead
becomes significant only in the degenerate cases where dozens of libraries
override Array.from.
David, I took your side in the TC39 meeting, as the meeting notes disclosed.
Rick prevailed (I think, my memory is hazy).
It's what I read from the notes too, but I feel something may have been
overlooked.
You want the polyfillers to pay the price, while Rick proposes that ES6's
built-in absorb arraylike fallback handling.
The difference is not in the polyfill (old browser) case, but in the present
and future (ES6 and above) cases: some objects will remain arraylike yet lack
@@iterator.
In ES6 and above, why would one create such an object? What's a good use case?
My understanding of the current consensus is that an arraylike without
@@iterator wouldn't work for for-of loops nor spread. Why not just create an
array? jQuery and Zepto want to subclass Array (one creates arraylike, the
other does subclass setting __proto__). It wasn't possible in ES5, but is in
ES6 with classes (and the super+@@create infrastructure).
jQuery is a bad example to use in this case, because it will _never_ include
features that can't be made to work consistently across all platforms that are
supported. This includes jQuery 2.x, which has no less and no more features or
capabilities than jQuery 1.x (and never will).
I feel that all the cases that justified arraylikes in the past have much
better alternatives in ES6.
My little experience building a Firefox addon even suggests that sets replace
arrays in most situations as most of what I do with arrays is .push, for-of and
.map/filter/reduce (by the way, Set.prototype needs these too, but another
topic for another time).
Realistically, this is a minority use case. The most common use case is a
web-based application that often must work on platforms as old as IE8, and that
shouldn't _limit_ the progress and evolution in ES6 features.
Why shouldn't Array.from help them out?
If these objects have a good reason to exist in an ES6 and above world, I
agree, that's a good point. But is there a use case justifying their existence?
In the ES6 world, there will be userland and platform objects that can't be
upgraded to real iterables, eg. application code that must behave correctly on
platforms with and without @@iterator (ie. browsers that have large market
share but don't auto-update). Array.from can be shimmed such that code like the
following will work correctly on both older ES3-5 (Array.prototype methods
shimmed for ES3) or ES6 platforms:
if (typeof Array.from === "undefined") {
...shim it.
}
function f() {
// Works correctly on browsers that have implemented @@iterator on
arguments objects
// as well as those that have not.
return Array.from(arguments).map(...);
}
// Or...
// Works correctly on browsers that have implemented @@iterator on NodeList
objects
// as well as those that have not.
Array.from(qSA(".selector")).forEach(...);
`for-of` won't even exist on these older platforms, but for code that only
needs to run on ES6 platforms, Array.from provides a "spread" or "make
iterable" mechanism for those objects that _can't_ be upgraded (for any reason,
as noted above):
// Turn a jQuery object into an iterable:
Array.from(jQuery(".selector"));
(This can't be done with spread)
Array.from bridges the gap between ES3/5 and ES6 while remaining useful in an
ES6 and post ES6 world by providing an "assimilation" path for objects that
have pre-existing constraints.
Rick
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
