ArrayClass should imply @@isConcatSpreadable
bzbarsky at MIT.EDU
Mon Oct 28 16:43:46 PDT 2013
On 10/28/13 7:13 PM, Anne van Kesteren wrote:
> On Mon, Oct 28, 2013 at 8:20 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> In terms of existing ArrayClass objects that are shipping on the web right
>> now, Gecko is shipping (though perhaps not in final releases yet) the .ports
>> of a MessageEvent and the return value of getClientRects(). I _think_
>> changing the concat() behavior of these should be OK. Certainly for .ports,
>> which we haven't been shipping for very long at all.
> Could we still change those to actual arrays? I guess for .ports that
> might be trickier as it implies a readonly view. ArrayClass feels like
> a hack.
getClientRects might be changeable.
.ports has exactly the problem you describe.
This came up today in a discussion of how we want to implement
https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html in Gecko,
and specifically how to implement the "axes" and "buttons" attributes on
Our current implementation returns vanilla JS arrays, but returns a
new one every get, which is pretty suboptimal. So we were considering
changing them to some ArrayClass interface and thinking about what
issues that might cause for callers...
If there is a better proposal for the "return an array that can be read
but not written but I can still write to it" use case, I'm all ears.
But as far as I can tell the way to do such a thing in ES is to return a
filtering proxy to an actual array. Such a proxy would of course fail
Array.isArray() checks, but presumably at some point proxies will be
able to control their @@isConcatSpreadable, right? Or so I would
hope... And then the proxy solution would quack a lot like ArrayClass
with my proposal, I think.
More information about the es-discuss