@@isConcatSpreadable
It's meant as an extension point. I believe some DOM list/array is supposed to use this.
Le 3 juin 2015 à 11:08, Axel Rauschmayer <axel at rauschma.de> a écrit :
people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat, 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.
Look at the IsConcatSpreadable abstract operation:
people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable
Note that, in absence of @@isConcatSpreadable property key, IsArray() is considered instead, so that builtin objects and constructors defined in the spec do not need to use @@isConcatSpreadable in order to get the right semantics.
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. 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?
Le 3 juin 2015 à 12:46, Leon Arnott <leonarnott at gmail.com> a écrit :
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. 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 careful consideration.
On Jun 3, 2015, at 3:46 AM, Leon Arnott wrote:
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. 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?
Exactly! ES6 has to preserve the previous semantics for all existing programs, including programs that attempted to create Array subclasses in various ad hoc manners.
@@isConcatSpreadable exists to allow new ES6-level array subclasses to explicitly opt-out of the legacy implicit spread behavior of concat.
Allen Wirfs-Brock wrote:
On Jun 3, 2015, at 3:46 AM, Leon Arnott wrote:
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. 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?
Exactly! ES6 has to preserve the previous semantics for all existing programs, including programs that attempted to create Array subclasses in various ad hoc manners.
@@isConcatSpreadable exists to allow new ES6-level array subclasses to explicitly opt-out of the legacy implicit spread behavior of concat.
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);
?
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 [].
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.