__proto__ security

Gavin Barraclough barraclough at apple.com
Sun Jan 29 15:25:27 PST 2012

On Jan 29, 2012, at 11:36 AM, Allen Wirfs-Brock wrote:
> Other standard properties that have accessor like characteristics but look like data properties:
> array element properties
> array length property
> string character element properties
> argument object elements 
> the "caller" property of function objects (see

The special handling for setting array length and and numeric properties fits well with the spec's existing division of labour between the [[Put]] and [[DefineOwnProperty]] algorithms, and is well encapsulated.  [[Put]] provides a simple set of rules for determining whether a [[DefineOwnProperty]] will be called on the base of the access, or whether a setter will be called on the prototype chain.  The 'magic' here is constrained to certain objects overriding the [[DefineOwnProperty]] trap (e.g.

It seems that any 'magic' to make __proto__ work in the proposed fashion could not be constrained to a [[DefineOwnProperty]] trap for the Object prototype, since if __proto__ is a data descriptor [[Put]] will trigger [[DefineOwnProperty]] trap on the base of the access.  Any special handling would either need to also rework [[Put]] to cause the special __proto__ trap to be triggered, or would need to be worked into Objects's [[DefineOwnProperty]] (8.12.9).  Any special handling in 8.12.9 would need to be non-trivial, since setting an object's __proto__ property would mean re-inspecting the prototype chain to see whether the nearest __proto__ was the magic data descriptor.  Either way seems unnecessarily complicated, and much less well encapsulated than Array's special handling of [[DefineOwnProperty]].

I just don't see why we would want to muddy up some core mechanisms of the object model, making them more difficult for users of the language to understand, for the non-benefit of making __proto__ appear to be something that it isn't.  It just seems like a bad idea wrapped in a bad idea to me.


More information about the es-discuss mailing list