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).

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).

> 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?

David

Le 28/12/2013 15:25, Brendan Eich a écrit :
> This seems overcomplicated. Isn't the likelier code something like
>
> ```js
> 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.

> 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).

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).

> 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?