B.3.1 The __proto__ pseudo property

Brendan Eich brendan at mozilla.com
Sun Apr 21 21:42:59 PDT 2013

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 

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

Re: Mark's

>  3) If we extend object literals with the computed name expression 
square-bracket syntax, consider
>      { [ e ]: .... }
>  where e is an expression that evaluates to the string "__proto__". 
This *must not* fall into the equivalent of the syntactic special case. 
To do so is to move the encoding error of #2 from code-generating 
programs to regular JS reflective programs.

I agree with Mark. This does indeed mean that

   n = "__proto__";
   o = { [n]: p }

will define a data property, not set inheritance. That's the only way 
quoting can matter, i.e.

   o = { ['__proto__']: p }

defines a plain old data property. No need to mimic JSON and make a 
quoted vs. unquoted difference without the [] for computed property 
names. Making that change requires a search of the web to find disproof, 
which is never a complete search, which leaves us hanging and makes 
implementors unhappy to take unknown risk.


More information about the es-discuss mailing list