B.3.1 The __proto__ pseudo property

Brendan Eich brendan at mozilla.com
Mon Apr 22 06:49:53 PDT 2013

Andreas Rossberg wrote:
> 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

Not poisoned for all calls, though -- see the meeting notes from January:


(find "__proto__" to search to start of the relevant notes).

> 3. __proto__ can be deleted from Object.prototype
> 4. __proto__ in object literals is a special piece of syntax
> independent from (1)

Should (4) be independent from (3)? Ah, you get to this later.

> 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.

That was discussed at the January meeting (I forget whether you were 
there then). Look for ARV in the notes, at the end of the __proto__ 

> 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 

>   If
> that's so then there is absolutely nothing magic remaining about
> __proto__ as a property.

Did you get something switched between A & B above? Either that, or I 
still need coffee!

> 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.

Ok, I can go along here. This is quite different from ES5 + de-facto 
__proto__ as implemented by real engines, but without configurable 
Object.prototype.__proto__ it has not thus far (AFAIK) been observable 
-- so no compatibility break.

>   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 


More information about the es-discuss mailing list