://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable).
Would've made the Array#concat() behaviour a little cleaner, in my
opinion.
Unless, perhaps, the point was to leave it open and allow the end-user
to monkey-patch it to false, thus finally fixing Array#concat()
after all these years
Herby Vojčík wrote:
So when one actually _wants_ to concat (as, add elements of the
iterable), it should stop using concat for that and must do something
like
var concatenated = first.slice();
concatenated.push(...second, ...third, ...fourth);
Or use concat but wrap the parameter with [].
It's meant as an extension point. I believe some DOM list/array is supposed
to use this.
On Wed, Jun 3, 2015 at 11:08 AM, Axel Rauschmayer a...@rauschma.de wrote:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat
I’m not seeing @@isConcatSpreadable being used
Le 3 juin 2015 à 11:08, Axel Rauschmayer a...@rauschma.de a écrit :
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat
I’m not seeing @@isConcatSpreadable being used
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat
I’m not seeing @@isConcatSpreadable being used as a property key anywhere in
the spec.
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es
This reminds me: I feel like the spec should've added
Array.prototype[Symbol.isConcatSpreadable] (value:true,
configurable:false, writable:false), and eliminated the final
IsArray() test from
[22.1.3.11](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable).
Would've made
://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable).
Would've made the Array#concat() behaviour a little cleaner, in my
opinion.
Given that inheriting from `Array.prototype` and being an Array object are
two distinct notions,
that would be a breaking change from the past that needs
/es6-draft.html#sec-isconcatspreadable).
Would've made the Array#concat() behaviour a little cleaner, in my
opinion.
Unless, perhaps, the point was to leave it open and allow the end-user
to monkey-patch it to false, thus finally fixing Array#concat()
after all these years...? Was that the plan
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
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
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:
On 28 October 2013 21:20, Boris Zbarsky bzbar...@mit.edu 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
* 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`.
You mean
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
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_
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
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
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
On Mon, Oct 28, 2013 at 4:13 PM, Anne van Kesteren ann...@annevk.nl 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
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
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 used
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).
And
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
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 identity
24 matches
Mail list logo
