B.3.1 The __proto__ pseudo property

Nathan Wall nathan.wall at live.com
Tue May 7 11:09:08 PDT 2013

>> Do you think we can come to some sort of agreement, as discussed below, 
>> that [[ProtoSetter]] doesn't need to be realm restricted. Such an 
>> agreement would let us write the simplest possible specification of 
>> __proto__. 
> Very timely question. I've discussed this within the other Cajadores 
> and the answer is yes. While the range restriction help security in 
> some ways, it doesn't help a lot, and it actually hurts in other 
> ways. Such simplicity itself is of benefit to security, and weighs in 
> the overall tradeoff. On balance we're better off without it. I'll be 
> posting publicly on this soon. 


>> It would also remove all obstacles to having Object.setPrototypeOf 
>> which a number of vocal community members would really prefer to have 
>> built-in and available rather than having to use __proto__ ugliness. 
> Yes. All objections to this disappear. And likewise for having proxies 
> handle trapping proto changes differently from their handling of other 
> changes. 

If I didn't misinterpret, this sounds like a very, very a welcome discussion -- one for which I would like to restate that I have a real use-case which is not 100% solvable with realm-confined __proto__[1].

I would like to add that, should `setPrototypeOf`, be admitted, it should work on objects which don't inherit from `Object.prototype` in order to settle my use-case (and also from a purist's point of view of how the language should behave). If `setPrototypeOf` is not admitted, I would hope that at least __proto__ will be a setter which can be retrieved with `getOwnPropertyDescriptor` and applied to objects which don't inherit from `Object.prototype`.

Please keep up the discussions around this issue!

[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html 		 	   		  

More information about the es-discuss mailing list