Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?

Domenic Denicola
Just an idle thought:

Many of the spec-compliance bugs in engines' array implementations over the last couple years have had to do with handling what happens when you e.g. install getters or setters on %ArrayPrototype%. I've been told that handling this case adds lots of complexity to the implementations and their optimizations.

Would it be worthwhile to explore making this impossible? Since %ArrayPrototype% is an exotic object anyway, we could give it a custom [[DefineOwnProperty]] that behaves similarly to that of array exotic objects, but disallows defining numeric keys. I guess this comes down to a few questions:

- Would this actually give gains for implementers? My information here is secondhand and inferred.
- Would the implementation complexity introduced by this change (separate exotic object types for arrays vs. %ArrayPrototype%) be worth the gains elsewhere, or is it just trading one weirdness for another?
- Is this feasibly web-compatible? (i.e. worth trying?)

Curious what implementers think.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?

Andreas Rossberg-4
As long as we have mutable __proto__ in the language that is not going to help. And even then, you'd have to restrict the whole prototype chain, including Object.prototype.

AFAICT, the only working solution is to change the behaviour of [[Get]] on arrays, such that they do not consider inherited numeric properties -- like typed arrays, or what we propose for strong mode arrays.

/Andreas


On 16 April 2015 at 05:23, Domenic Denicola <[hidden email]> wrote:
Just an idle thought:

Many of the spec-compliance bugs in engines' array implementations over the last couple years have had to do with handling what happens when you e.g. install getters or setters on %ArrayPrototype%. I've been told that handling this case adds lots of complexity to the implementations and their optimizations.

Would it be worthwhile to explore making this impossible? Since %ArrayPrototype% is an exotic object anyway, we could give it a custom [[DefineOwnProperty]] that behaves similarly to that of array exotic objects, but disallows defining numeric keys. I guess this comes down to a few questions:

- Would this actually give gains for implementers? My information here is secondhand and inferred.
- Would the implementation complexity introduced by this change (separate exotic object types for arrays vs. %ArrayPrototype%) be worth the gains elsewhere, or is it just trading one weirdness for another?
- Is this feasibly web-compatible? (i.e. worth trying?)

Curious what implementers think.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?

Axel Rauschmayer
As long as we have mutable __proto__ in the language that is not going to help. And even then, you'd have to restrict the whole prototype chain, including Object.prototype.

AFAICT, the only working solution is to change the behaviour of [[Get]] on arrays, such that they do not consider inherited numeric properties -- like typed arrays, or what we propose for strong mode arrays.

Would it help if one introduced new methods `get()` and `set()` for accessing array elements? They could be overridden, but that seems like a simpler, more optimizable check.

-- 
Dr. Axel Rauschmayer
[hidden email]
rauschma.de




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss