then what's the point to poison Object.getOwnPropertyDescriptor(Object.prototype, "__proto__").set if anyone can always use __proto__ to change the chain ?
I don't understand this poisoning ... I don't see any advantage, only problems if some library would like to drop __proto__ and use in edge case that setter for good. Thanks for clarifications On Mon, Apr 22, 2013 at 1:15 PM, Allen Wirfs-Brock <[email protected]>wrote: > We don't currently have the concept of an object "belonging" to a realm. > Functions have a realm association, but not non-function object. > > Object.create(parent); //we have no way to determine if parent > "belongs" to the same realm as Object.create. > we also currently have no way to determine whether the caller of > Object.create is in the same or different realm as Object.create. > > someObject.__proto__ = someParent; //the setter function from > Object.prototype has no way to determine a realm association for someParent. > > let protoSetter = Object.getOwnPropertyDescriptor(Object.prototype, > "__proto__"); //a proto setter from some realm > > let x = {}; > protosetter.call(x, another); //no realm info to validate. > > protosetter is essentially a universal setPrototypeOf function. > > The only way I see to tame any aspect (for example not allowing > Object.prototype.__proto__ = something) of __proto__ setting is via a > [[Set]] over-ride on Object.prototype. > > Allen > > > > On Apr 22, 2013, at 7:29 AM, Andreas Rossberg wrote: > > > On 22 April 2013 15:49, Brendan Eich <[email protected]> wrote: > >>> However, in that case, I actually think that there is no need to have > >>> any special poisoning semantics when reflecting __proto__ -- mainly > >>> because the cross-realm check is already necessary in the unreflected > >>> case: you can construct an object o in realm A with an > >>> Object.prototype from another realm B on its proto chain. If you > >>> deleted __proto__ on realm's A Object.prototype, I don't think it > >>> should still be possible to assign to o.__proto__, should it? > >> > >> Why not, if in realm A we evaluate 'var o = > >> Object.create(B.Object.prototype)'? You specified 'delete > >> A.Object.prototype' happened, and A.Object.prototype is not on o's proto > >> chain. > > > > My understanding of the motivation for poisoning was to enable the > > deletion of O.p.__proto__ when configuring a realm as a means for > > guaranteeing that no object from that realm can ever have its > > prototype mutated. Allowing the above case would seem to shoot a hole > > into that. > > > > // Realm A > > delete Object.prototype.__proto__ // no messing around > > > > let other = getObjectFromSomewherePotentiallyAnotherRealmB() > > > > let p1 = Object.create(other, {a: {value: 1}}) > > let o = Object.create(p1) > > let p2 = Object.create({}) > > o.__proto__ = p2 // say what? > > > > > >>> Whether a > >>> difference should be made between quoted and unquoted I don't know, I > >>> must have missed the rationale for such a move. > >> > >> I think we're not going to induce vomiting by making a quoted vs. > unquoted > >> distinction, in light of Mark's point about computed property names. > > > > OK, good. :) > > > > /Andreas > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
