github at esdiscuss.org (2013-07-12T02:26:57.267Z)
I have difficulties catching up with everything that has been said in this thread, my apologies if I repeat parts of the discussion. Here is what I thought we agreed upon earlier: 1. `__proto__` is an accessor property on `Object.prototype` 2. reflecting it via `Object.getOwnPropertyDescriptor` gives you a poisoned setter 3. `__proto__` can be deleted from `Object.prototype` 4. `__proto__` in object literals is a special piece of syntax independent from (1) I think this all makes sense, and we are working towards making V8 implement this. (3) implies that `Object.prototype.__proto__` is configurable, which should also imply that you can just remove the setter, not the getter, which I believe addresses Alex' initial request. The main question I still had was what "poisoning" means. Currently, V8 simply returns an always-throw function. Others (e.g. Brendan) seemed to assume that we only poison sets for other realms. 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? If that's so then there is absolutely nothing magic remaining about `__proto__` as a property. As for `__proto__` in object literals, I definitely agree with Allen and Mark that this should be special syntax, and not dependent on `Object.prototype.___proto__`, for the reasons mentioned. 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 have difficulties catching up with everything that has been said in this thread, my apologies if I repeat parts of the discussion. Here is what I thought we agreed upon earlier: 1. __proto__ is an accessor property on Object.prototype 2. reflecting it via Object.getOwnPropertyDescriptor gives you a poisoned setter 3. __proto__ can be deleted from Object.prototype 4. __proto__ in object literals is a special piece of syntax independent from (1) I think this all makes sense, and we are working towards making V8 implement this. (3) implies that Object.prototype.__proto__ is configurable, which should also imply that you can just remove the setter, not the getter, which I believe addresses Alex' initial request. The main question I still had was what "poisoning" means. Currently, V8 simply returns an always-throw function. Others (e.g. Brendan) seemed to assume that we only poison sets for other realms. 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? If that's so then there is absolutely nothing magic remaining about __proto__ as a property. As for __proto__ in object literals, I definitely agree with Allen and Mark that this should be special syntax, and not dependent on Object.prototype.___proto__, for the reasons mentioned. Whether a difference should be made between quoted and unquoted I don't know, I must have missed the rationale for such a move. /Andreas On 22 April 2013 13:43, Brendan Eich <brendan at mozilla.com> wrote: > Mark Miller wrote: > >> On Sun, Apr 21, 2013 at 9:42 PM, Brendan Eich <brendan at mozilla.com >> <mailto:brendan at mozilla.com>> wrote: >> >> Ok, so (after pushing back based on recorded consensus, which I >> think is fair), I'm ok with >> >> * Object.prototype.__proto__ is configurable. >> >> * o = {__proto__: p} semantics changes from ES5's [[Put]] to ES6's >> [[SetInheritance]]. >> >> I'm not sure everyone agrees, but let's assume these two. >> >> Why, given these, must Object.prototype.__proto__ not reflect at >> all via Object.getOwnPropertyDescriptor? >> >> >> What? Where is that proposed? (And again, I am jumping into this thread in >> the middle, so apologies for lack of context.) > > > Up-thread, near the o.p.: > > https://mail.mozilla.org/pipermail/es-discuss/2013-April/029962.html > > >> What about Object.getOwnPropertyNames? We have to sink some cost >> somewhere, and TC39 had a January near-consensus of "accessor, >> with get and set functions that throw on cross-realm |this| vs. >> the accessor function". That seems the best solution to me still, >> and it should fall out of cross-window/frame wrapper policy hooks >> fairly cheaply in SpiderMonkey. >> >> >> That sounds good to me too. Where is the alternative explained? > > > https://mail.mozilla.org/pipermail/es-discuss/2013-April/029962.html which > links to a PDF. > > > /be > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss