David Bruant wrote:
> Based on what I suggested (internalize iterators in Array.from code 
> for polyfills), the ES5 equivalent is to override Array.from as such:
>
> ````js
> (function(){
>     var nativeArrayFrom = Array.from;
>
>     Array.from = function(x){
>         if(/*x is of my library type*/){
>             /* generate an equivalent array using the traversal logic
>                 that would be used for its @@iterator in ES6
>             */
>         }
>         else{
>             return nativeArrayFrom(x);
>         }
>     }
>
> })()
> ````

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?

> 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). 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. Why shouldn't Array.from help them out?

/be

David Bruant wrote:
> Based on what I suggested (internalize iterators in Array.from code 
> for polyfills), the ES5 equivalent is to override Array.from as such:
>
> ````js
> (function(){
>     var nativeArrayFrom = Array.from;
>
>     Array.from = function(x){
>         if(/*x is of my library type*/){
>             /* generate an equivalent array using the traversal logic
>                 that would be used for its @@iterator in ES6
>             */
>         }
>         else{
>             return nativeArrayFrom(x);
>         }
>     }
>
> })()
> ````

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?

> 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). 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. Why shouldn't Array.from help them out?