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.

My preferred spec for it is at http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_may_21_2013&cache=cache&media=meetings:rev_15_proto_.pdf 

Note that the behavior that some people have expressed a preference for (Dunder proto is observably an accessor property but its set function when retrieved always throws) will also require an exotic Object prototype object to specify so my proposal is not adding any spec. complexity.

As an exercise to the reader, it isn't hard to demonstrate that specified approach could be expressed by using a Proxy to defined Object.prototype (if the proxy handler had access to [[SetInheritance]]).  Since proxy objects are allowed to occur on the [[Prototype]] chain, if an implementation has the mechanism to implement Proxy it will also have the mechanism necessary to implement this definition of  Dunder proto.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130421/ec927388/attachment.html>

On Apr 21, 2013, at 5:22 AM, David Bruant wrote:

> Le 21/04/2013 01:37, Axel Rauschmayer a ?crit :
>> 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:
> ```js
> 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.

My preferred spec for it is at http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_may_21_2013&cache=cache&media=meetings:rev_15_proto_.pdf 

Note that the behavior that some people have expressed a preference for (Dunder proto is observably an accessor property but its set function when retrieved always throws) will also require an exotic Object prototype object to specify so my proposal is not adding any spec. complexity.

As an exercise to the reader, it isn't hard to demonstrate that specified approach could be expressed by using a Proxy to defined `Object.prototype` (if the proxy handler had access to [[SetInheritance]]).  Since proxy objects are allowed to occur on the [[Prototype]] chain, if an implementation has the mechanism to implement Proxy it will also have the mechanism necessary to implement this definition of  Dunder proto.