On Saturday, December 28, 2013, Domenic Denicola wrote:

>  Why can't jQuery do
>
> ```js
> if (typeof Symbol !== "undefined" && Symbol.iterator) {
>     jQuery.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator];
> }
> ```
>

For the same reason I've stated here any time anyone ever brings up
anything anything jQuery "might" do: jQuery doesn't ship anything in core
that cannot be made to work consistently in all browsers that both 1.x and
2.x are expected to support. Additionally, jQuery has never and will never
ship "conditional" features in the core library.


Rick



 ------------------------------
> From: Rick Waldron <javascript:_e({}, 'cvml', 'waldron.rick at gmail.com');>
> Sent: 12/28/2013 14:24
> To: David Bruant <javascript:_e({}, 'cvml', 'bruant.d at gmail.com');>
> Cc: Brendan Eich <javascript:_e({}, 'cvml', 'brendan at mozilla.com');>;
> EcmaScript <javascript:_e({}, 'cvml', 'es-discuss at mozilla.org');>
> Subject: Re: Overly complicated Array.from?
>
>
>
>
> On Sat, Dec 28, 2013 at 11:37 AM, David Bruant <bruant.d at gmail.com> 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 cor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131228/25ac9d69/attachment.html>

On Saturday, December 28, 2013, Domenic Denicola wrote:

>  Why can't jQuery do
>
> ```js
> if (typeof Symbol !== "undefined" && Symbol.iterator) {
>     jQuery.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator];
> }
> ```
>

For the same reason I've stated here any time anyone ever brings up
anything anything jQuery "might" do: jQuery doesn't ship anything in core
that cannot be made to work consistently in all browsers that both 1.x and
2.x are expected to support. Additionally, jQuery has never and will never
ship "conditional" features in the core library.