> Le 28 déc. 2013 à 13:05, David Bruant <bruant.d at gmail.com> a écrit :
> 
> Le 27/12/2013 19:10, Claude Pache a écrit :
>> There is still the issue of potential libraries that produce arraylikes that don't inherit from a built-in arraylike prototype: those won't benefit from your polyfill without changing their inheritance strategy.
> I don't understand the expression "inherit from a built-in arraylike prototype". Could you explain this further?

Examples of what I tried to designate by the compact expression "built-in arraylike prototype": `NodeList.prototype`, `Array.prototype`, `Arguments.prototype`. For instance, if an object inherits from `NodeList.prototype`, there is a good chance that it will be detected as NodeList by your polyfill, and therefore be handled as an array-like. (Otherwise, yes, monkey-patching `Array.from` case-by-case remains possible.)

—Claude

Le 28 déc. 2013 à 13:05, David Bruant <bruant.d at gmail.com> a écrit :
> Le 27/12/2013 19:10, Claude Pache a écrit :
>> There is still the issue of potential libraries that produce arraylikes that don't inherit from a built-in arraylike prototype: those won't benefit from your polyfill without changing their inheritance strategy.
>
> I don't understand the expression "inherit from a built-in arraylike prototype". Could you explain this further?

Examples of what I tried to designate by the compact expression "built-in arraylike prototype": `NodeList.prototype`, `Array.prototype`, `Arguments.prototype`. For instance, if an object inherits from `NodeList.prototype`, there is a good chance that it will be detected as NodeList by your polyfill, and therefore be handled as an array-like. (Otherwise, yes, monkey-patching `Array.from` case-by-case remains possible.)