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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
