On Apr 21, 2013, at 10:03 AM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Apr 21, 2013, at 5:22 AM, David Bruant wrote:
>>> Hi Axel,
>>> 
>>> Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
>>>> __proto__ can be globally switched off by deleting Object.prototype.__proto__. I’m assuming that that is useful for security-related applications (Caja et al.). But I’m wondering: doesn’t that go too far? I’m seeing three ways of using __proto__:
>>>> 
>>>> 1. Read the [[Prototype]] of an object. Already possible via Object.getPrototypeOf().
>>>> 2. Set the [[Prototype]] of a fresh object created via an object literal (i.e., an alternative to the rejected <| operator). Already (kind of) possible via Object.create().
>>> Also possible with class syntax and the "extends" keyword (with all the @@create internal semantics).
>>> 
>>>> 3. Mutate the [[Prototype]] of an existing object.
>>>> 
>>>> Globally, I would only want to switch off #3.
>>> You can re-enable #1 by re-adding Object.prototype.__proto__ as your own getter wrapping Object.getPrototypeOf. Or maybe instead of "delete Object.prototype.__proto__", just do:
>>>    Object.defineProperty(Object.prototype, "__proto__", {set: undefined});
>> 
>> I still think that Dunder proto should not be exposed at all by Object.getOwnPropertyDescriptor (or any other reflection)  and that there is no need to leak either a working or always throwing __proto__ setter function into the hands of a ES programmer.
> 
> This isn't what we seemed to agree on at past TC39 meetings.
> 
> It's also not what the engines trying to converge on ES6 semantics have implemented.

It's not clear to me, yet what convergence we actually have.

Regardless, it's only observable via Object.getOwnPropertyDescriptor(Object.prototype, "__proto__") which in my proposal returns undefined when Dunder proto is active and in other proposals returns a function that when evaluated throws something.  The semantics of Dunder proto that have been discussed isn't just  that of an accessor property and can't be purely implemented as such so I no value in trying to masquerade it as an accessor for getOwnPropertyDescriptor.  Returning get/set functions that always throws is just adding complexity that delivers no value. 

Allen

On Apr 21, 2013, at 10:03 AM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> I still think that Dunder proto should not be exposed at all by `Object.getOwnPropertyDescriptor` (or any other reflection)  and that there is no need to leak either a working or always throwing `__proto__` setter function into the hands of a ES programmer.
> 
> This isn't what we seemed to agree on at past TC39 meetings.
> 
> It's also not what the engines trying to converge on ES6 semantics have implemented.

It's not clear to me, yet what convergence we actually have.

Regardless, it's only observable via `Object.getOwnPropertyDescriptor(Object.prototype, "__proto__")` which in my proposal returns undefined when Dunder proto is active and in other proposals returns a function that when evaluated throws something.  The semantics of Dunder proto that have been discussed isn't just  that of an accessor property and can't be purely implemented as such so I no value in trying to masquerade it as an accessor for `getOwnPropertyDescriptor`.  Returning get/set functions that always throws is just adding complexity that delivers no value.