the polyfill for Array.from is based on slice 'cause slice works like that
since, well, ever.
That's why I've raised some concern about a change on slice ... I'd rather
extend a new `ArrayObject` instead of touching `Array` also because
polyfills will make common/borrowed slice operations painfully slow.
My point is: `Array` has never been subclassed and nobody is expecting to
be able to do that with current semantics/code/libraries if not redefining
and delegating.
ES6 introduces new syntax that should desugar to what every browsers know
already ... it's "easy", when possible, to polyfill a new global class ...
it will make polyfills very painful otherwise.
I can already imagine ES6 shim overwriting all `Array.prototype` methods to
obtain this new behavior ... it would be much easier to do this instead:
```javascript
function ArrayObject() {}
ArrayObject.prototype.slice = function () {
return Object.setPrototypeOf(
Array.prototype.slice.call(this, arguments),
Object.getPrototypeOf(this)
);
};
```
Cheers
On Tue, Sep 10, 2013 at 3:24 PM, Rick Waldron <[email protected]>wrote:
>
>
>
> On Tue, Sep 10, 2013 at 1:37 PM, Andrea Giammarchi <
> [email protected]> wrote:
>
>> I see one of two problems mentioned in my other topic is already
>> discussed here so I'd like to add this question that will most likely break
>> the web:
>>
>> 1. will `[].slice.call(arguments)` produce a pointless instanceof
>> Arguments ?
>>
>
> No, because you can't construct `new Arguments()` (Arguments is
> undefined), leaving A undefined at step 15.c, which means step 16 evaluates
> to true, which leads to 16.a and that produces an Array.
>
>
>
>> 2. will `[].slice.call(document.querySelectorAll('*'))` produce an
>> instanceof Static NodeList ?
>>
>
> This is a good question, if NodeList has an internal [[Construct]] it will
> pass the IsConstructor test and then throw a TypeError exception as soon as
> 15.c.i occurs. Based on my interpretation of the steps in
> OrdinaryConstruct, it wouldn't survive. Maybe Allen can clarify?
>
> Also, this is the exact pain point case that Array.from was designed to
> address, but existing code shouldn't break in the interim.
>
> Rick
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
