B.3.1 The __proto__ pseudo property

Andreas Rossberg rossberg at google.com
Mon Apr 22 06:22:24 PDT 2013

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

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.


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

More information about the es-discuss mailing list