Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor
property, not an Array.prototype property.
Minomer, then -- how about Symbol.isArrayClass?
we also change Array.prototype.concat to do the above Array.isArray
test instead of using @@comcatSpreadable and change JSON.stringify to
use this test where it current checks for an exotic array object.
Then we have the following:
assert(Array.isArray( [ ] )); //just like ES5
assert( ! Array.isArray( Object.create(Array.prototype))); //just like ES5
How so? True:
js> Array.isArray(Array.prototype)
true
js> Array.isArray(Object.create(Array.prototype))
false
but constructor isn't shadowed:
js> Array.prototype.constructor
function Array() {
[native code]
}
js> Object.create(Array.prototype).constructor
function Array() {
[native code]
}
assert (new class extends Array{}); //ES6 Array subclass instances
answer true unless the subclass over-rides the static @@isArray property
assert(new class extends Array {
constructor() {return {}};
}); // even if the subclass instance isn't an exotic array object
(this is an improvement over the current ES6 spec. which says that
//isArray answers false in this case
assert(new Proxy( [ ], { }); //because it's all done with property
access, no instance inspection required.
(These want Array.isArray inside assert, of course.)
assert( ! new Int32Array(10)); //not array-like, just like ES5
However, I think we should experiment with giving %TypedArrau% is true
valued @@isArray property. I'm guessing that this change won't
actually break anything.
Probably ok.
the above proposal completely decouples Array.isArray from exotic
array object checking or any other direct instance inspection.
Everything works at the property access level and so is (by default)
transparent to proxies and completely controllable at the ES cod level.
Righteous goal!
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
