__proto__ security

Gavin Barraclough barraclough at apple.com
Sun Jan 29 17:28:04 PST 2012

Hi Allen,

On Jan 29, 2012, at 4:25 PM, Allen Wirfs-Brock wrote:
> There are no rules  that constrain [[Put]] in this manner you are suggesting.

Sorry, perhaps my comments were unclear.  The observation I was intending to highlight was only that the current behaviour of [[Put]] will be to call [[DefineOwnProperty]] on a base object that is not the object that logically contains the 'magic' property, if the __proto__ is specified as a data descriptor.


> Object.prototype.__p__ = 1;
> var a = {};
> a.__p__ = 2;

The [[Put]] of '2' will call the [[DefineOwnProperty]] trap of 'a', not the object that currently contains a data descriptor for __p__.

Hence (as I think you recognize in your comments), it would not simply be sufficient to provide an overridden implementation for [[DefineOwnProperty]] for the object prototype.  This does mean that the 'magic' behaviour cannot be as easily and cleanly encapsulated as it can for Array, where the 'magic' properties are directly on the base object passed to [[DefineOwnProperty]].

> This seems like a perfectly reasonable way to specify this.  As __proto__ does indeed affect the property access semantics for every object.   Of course, I'm only talking specification.  How you accomplish it in your implementation is up to you.
> There are other, alternatives.

I'm not questioning for a minute that this is possible – it certainly is – I'm just stating that it seems to be completely unnecessary, confusing, and not a good idea to do so. :-)  Seriously, why are we doing this? – __proto__ is an accessor, it's much simpler to just spec it as such, why are we trying to set up hoops for ourselves to jump through to avoid doing so?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120129/c6b7d14a/attachment.html>

More information about the es-discuss mailing list