ArrayClass should imply @@isConcatSpreadable

Boris Zbarsky 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> 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 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 mailing list