Array.prototype.slice web-compat issue?

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Sep 10 16:11:13 PDT 2013


Rick I think I've often seen this which is not that naive accordingly with
ES 5.1 down to ES 3 specs, IMO .. it worked with DOM, arguments, and
everything with a `length` till now.

```javascript
Array.from||(Array.from=function(a){return Array.prototype.slice.call(a)});
```

Allen the `%TypedArray%` is a good example because this is false: `new
Float32Array instanceof Array` ... that constructor has even the suffix
with the `Array` word but is not an `Array` at all.

`Array.isArray(new Float32Array)` is again false indeed.

I also think this magic should somehow be something new, hoping nobody will
think about creating polyfills for all Array methods because once again
that will be very bad for the web/mobile/ARM world, IMO.

Thanks for all answers though.




On Tue, Sep 10, 2013 at 3:57 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Sep 10, 2013, at 3:24 PM, Rick Waldron wrote:
>
>
>
>
> On Tue, Sep 10, 2013 at 1:37 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> 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.
>
>
> Exactly, as currently spec'ed slice applied to an arguments object or any
> Array.isArray false produce an instance of Array from the same realm as the
> slice function.
>
>
>
>>   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?
>
>
> See %TypedArray%.prototype.slice
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-22.2.3.24 which
> in some subtle ways is a cleaner and more general versions of Array slice.
>
> But, in either version I'm not very happy with just assuming that
> this.constructor(n) produces a new this.constructor instance of size n.
>  I'm seriously thinking about specify a @@ method on Arrays and other
> collections that allocates a new instance of a given size.  perhaps
> Array[@@newSized](n)
>
> In that case, NodeList could define @@newSized and it would work with
> either version of slice.
>
>
> Also, this is the exact pain point case that Array.from was designed to
> address, but existing code shouldn't break in the interim.
>
>
> Right, there are several ways in ES6 to force creation of an initialized
> Array include [...collection] and Array.from
>
> And for existing code, it should just keep working although we have to
> address the Realm issue.
>
> The other less obvious question is what should happen when old code is
> combined with new code that uses Array subclassing. My position, is that it
> will usually just work, but its is essentially newly new code and there may
> be a few edge cases that the older parts of the code didn't anticipate.
>  Test is probably required.
>
> allen
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130910/03932571/attachment.html>


More information about the es-discuss mailing list