>> 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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
