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