Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

[Brendan Eich]

Allen Wirfs-Brock wrote:
> We might redefine Array.isArray to be based upon testing for 
> @@isConcatSpreadable but that potentially would give different results 
> for legacy uses that did __proto__ hacking such as I mentioned in my 
> previous mote.

How about we turn the @@ property into @@isArrayLike or 
@@isStronglyArrayLike if you insist.

>> Now, if we take the meaning of Array.isArray to be "supports the 
>> Array.prototype utility methods", a proxy-for-array may of course 
>> expose a totally different API, leading a client that expects to be 
>> able to use the Array.prototype methods to fail. But this foregoes 
>> the fact that for virtually all practical use cases of proxies, proxy 
>> authors will not do this. They want to be able to wrap objects, 
>> intercept some things, but mostly faithfully forward those operations 
>> to the wrapped target. It would be rare for a proxy to change the API 
>> of the thing it wraps. Indeed, the whole point of proxies is to be 
>> able to intercept operations without modifying client code.
>
> Certainly if you use a proxy to define a virtual object, to self-host, 
> spec-defined exotic objects or to implement DOM objects you just 
> aren't transparently wrapping the target object...
>
> I think at the root of this is that many JS programmer don't really 
> understand what is (or isn't special about Array instances and that 
> Array.isArray may have just added to the confusion.

That may be, but (part of) our job is to help them. So progressively 
refining the meaning via @@isArrayLike seems winning.

/be