Re: ArrayClass should imply @@isConcatSpreadable

* Allen Wirfs-Brock wrote: >On Oct 28, 2013, at 5:52 PM, Domenic Denicola wrote: > >> From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] >> >>> So what's so onerous about returning a fresh array from the getter each >>> time it was called. >> >> The fact that `api.property !== api.property`.

Re: ArrayClass should imply @@isConcatSpreadable

On 28 October 2013 21:20, Boris Zbarsky wrote: > As far as I can tell, the two places in ES5 that test [[Class]] being equal > to "Array" are Array.isArray() and Array.prototype.concat. > > In ES6, the former does some sort of brand check, but the latter calls > IsConcatSpreadable, which checks fo

Re: ArrayClass should imply @@isConcatSpreadable

On 10/28/13 8:50 PM, Allen Wirfs-Brock wrote: So what's so onerous about returning a fresh array from the getter each time it was called. If it was implemented in Es6, it would just be: return Array.from(internal_compy); Implementing this is pretty easy, for sure. The questions are: 1)

Re: ArrayClass should imply @@isConcatSpreadable

On 10/28/13 8:08 PM, Jonas Sicking wrote: Return a frozen (and thus immutable) Array. When you need to change the contents of the array, create a new frozen Array which contains the new Array contents. Ah, hmm. I could probably live with that. -Boris __

Re: ArrayClass should imply @@isConcatSpreadable

On 10/28/13 7:54 PM, Jonas Sicking wrote: Lets just return a frozen Array. That works for .ports, I think, but not for the gamepad API case: in that case the array can change as gamepads are connected or disconnected... -Boris ___ es-discuss mailin

Re: ArrayClass should imply @@isConcatSpreadable

On Oct 28, 2013, at 5:52 PM, Domenic Denicola wrote: > From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] > >> So what's so onerous about returning a fresh array from the getter each time >> it was called. > > The fact that `api.property !== api.property`. > You mean people want to do id

RE: ArrayClass should imply @@isConcatSpreadable

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] > So what's so onerous about returning a fresh array from the getter each time > it was called. The fact that `api.property !== api.property`. ___ es-discuss mailing list es-discuss@mozilla.org htt

Re: ArrayClass should imply @@isConcatSpreadable

On Oct 28, 2013, at 5:25 PM, Domenic Denicola wrote: > > I think the issue is that these things are properties, either because of web > legacy (as in some specifications) or because the spec writers conceptualize > them as such and are reluctant to change them (for the newer specifications). >

RE: ArrayClass should imply @@isConcatSpreadable

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Allen > I don't think there is any thing wrong with using Object.freeze if you really > need to return an immutable object. But what's wrong with returning a fresh > object each time? Are these operations highly likely to be use

Re: ArrayClass should imply @@isConcatSpreadable

On Oct 28, 2013, at 4:43 PM, Boris Zbarsky wrote: > ... > 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 >

Re: ArrayClass should imply @@isConcatSpreadable

On Mon, Oct 28, 2013 at 4:43 PM, Boris Zbarsky wrote: > 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. My suggestion has been: Return a frozen (and thus immutable) Array. When you need to change the c

Re: ArrayClass should imply @@isConcatSpreadable

On Mon, Oct 28, 2013 at 4:13 PM, Anne van Kesteren wrote: > On Mon, Oct 28, 2013 at 8:20 PM, Boris Zbarsky 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

Re: ArrayClass should imply @@isConcatSpreadable

On 10/28/13 7:43 PM, Boris Zbarsky wrote: 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... To be

Re: ArrayClass should imply @@isConcatSpreadable

On 10/28/13 7:43 PM, Boris Zbarsky wrote: 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... To be

Re: ArrayClass should imply @@isConcatSpreadable

On 10/28/13 7:13 PM, Anne van Kesteren wrote: On Mon, Oct 28, 2013 at 8:20 PM, Boris Zbarsky 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 g

Re: ArrayClass should imply @@isConcatSpreadable

On Mon, Oct 28, 2013 at 8:20 PM, Boris Zbarsky 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 c

ArrayClass should imply @@isConcatSpreadable

As far as I can tell, the two places in ES5 that test [[Class]] being equal to "Array" are Array.isArray() and Array.prototype.concat. In ES6, the former does some sort of brand check, but the latter calls IsConcatSpreadable, which checks for a @@isConcatSpreadable symbol. It seems to me like