On 10/28/13 7:13 PM, Anne van Kesteren wrote:
On Mon, Oct 28, 2013 at 8:20 PM, Boris Zbarsky <bzbar...@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.
Thoughts?
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
<https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#gamepad-interface>.
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.
-Boris
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
