B.3.1 The __proto__ pseudo property
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
> 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
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__.
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!
More information about the es-discuss