So here is the plan that I'll review at the next TC39 meeting:

1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in order to change its [[Prototype]]. There are no realm restrictions.  It's just like all the other Object.* methods in operating on any object, independent of realm association.  

2) Object.prototype.__proto__ is moved back to Annex B. It is defined as an accessor property with attributes {enumerable: true, configurable: true}.  The get and set functions are defined equivalently to Object.setPrototypeOf and Object.getPrototypeOf.  No realm restrictions.  No reflection restrictions. Object.getOwnPropertyNames(Object.prototype) includes "__proto__".

3) __proto__ as a property key in an object literal (but not a class definition) is syntax with special semantics of setting the literal object's [[Prototype]] when it is created.  It is a clause 11 feature and is not tied to the presence of  Object.prototyype.__proto__. 

4) Both Object.setPrototypeOf and Object.prototype.__proto__ are defined in terms of the [[SetInheritance]]/[[GetInhertiance]] MOP operations (the names can still change).  There are  corresponding Proxy traps.  There are no exceptional restrictions placed on the handlers.  Just the normal invariants. In particular, if the target is non-extensible then the [[SetInheritaqnce]] Proxy handler can't change the observable [[GetInhertance]] result for the proxy object.

Allen

On May 7, 2013, at 12:18 PM, Mark Miller wrote:

> 
> 
> 
> On Tue, May 7, 2013 at 11:09 AM, Nathan Wall <nathan.wall at live.com> wrote:
> >> Do you think we can come to some sort of agreement, as discussed below, 
> >> that [[ProtoSetter]] doesn't need to be realm restricted. Such an 
> >> agreement would let us write the simplest possible specification of 
> >> __proto__. 
> > 
> > Very timely question. I've discussed this within the other Cajadores 
> > and the answer is yes. While the range restriction help security in 
> > some ways, it doesn't help a lot, and it actually hurts in other 
> > ways. Such simplicity itself is of benefit to security, and weighs in 
> > the overall tradeoff. On balance we're better off without it. I'll be 
> > posting publicly on this soon. 
> 
> ...
> 
> >> It would also remove all obstacles to having Object.setPrototypeOf 
> >> which a number of vocal community members would really prefer to have
> >> built-in and available rather than having to use __proto__ ugliness.
> >
> > Yes. All objections to this disappear. And likewise for having proxies
> > handle trapping proto changes differently from their handling of other
> > changes.
> 
> 
> If I didn't misinterpret, this sounds like a very, very a welcome discussion -- one for which I would like to restate that I have a real use-case which is not 100% solvable with realm-confined __proto__[1].
> 
> I would like to add that, should `setPrototypeOf`, be admitted, it should work on objects which don't inherit from `Object.prototype` in order to settle my use-case (and also from a purist's point of view of how the language should behave). If `setPrototypeOf` is not admitted, I would hope that at least __proto__ will be a setter which can be retrieved with `getOwnPropertyDescriptor` and applied to objects which don't inherit from `Object.prototype`.
> 
> Agreed on both. The only restriction we need is the one that ES5 already gives us: You can't change the [[Prototype]] of a non-extensible object.
> 
>  
> 
> Please keep up the discussions around this issue!
> 
> 
> 
> [1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
> Text by me above is hereby placed in the public domain
> 
>   Cheers,
>   --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/868e4617/attachment-0001.html>

So here is the plan that I'll review at the next TC39 meeting:

1. Add `Object.setPrototypeOf(obj, proto)`

   A obj must be extensible in order to change its [[Prototype]]. There are no realm restrictions.  It's just like all the other `Object.*` methods in operating on any object, independent of realm association.  

2. `Object.prototype.__proto__` is moved back to Annex B. It is defined as an accessor property with attributes `{enumerable: true, configurable: true}`.  The get and set functions are defined equivalently to `Object.setPrototypeOf` and `Object.getPrototypeOf`.  No realm restrictions.  No reflection restrictions. `Object.getOwnPropertyNames(Object.prototype)` includes `"__proto__"`.

3. `__proto__` as a property key in an object literal (but not a class definition) is syntax with special semantics of setting the literal object's [[Prototype]] when it is created.  It is a clause 11 feature and is not tied to the presence of  `Object.prototype.__proto__`.

4. Both `Object.setPrototypeOf` and `Object.prototype.__proto__` are defined in terms of the [[SetInheritance]]/[[GetInheritance]] MOP operations (the names can still change).  There are  corresponding Proxy traps.  There are no exceptional restrictions placed on the handlers.  Just the normal invariants. In particular, if the target is non-extensible then the [[SetInheritance]] Proxy handler can't change the observable [[GetInheritance]] result for the proxy object.