On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock <
allen.wirfsbrock at gmail.com> wrote:

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

+1



>
> 2) Object.prototype.__proto__ is moved back to Annex B.
>

Since __proto__, unlike __defineGetter__, provides functionality that is
otherwise unavailable, all JS platforms will treat it as mandatory whether
we put it into Appendix B or the main text. At this point, I think moving
this back to Appendix B would be an obviously meaningless gesture




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

+1



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

I hadn't thought about this irregularity if it appears within a class
definition. That aside, +1.



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

+1. Excellent!



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


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/7ca965df/attachment.html>

On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock <allen.wirfsbrock at gmail.com> wrote:

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

+1



> 2) `Object.prototype.__proto__` is moved back to Annex B.

Since `__proto__`, unlike `__defineGetter__`, provides functionality that is
otherwise unavailable, all JS platforms will treat it as mandatory whether
we put it into Appendix B or the main text. At this point, I think moving
this back to Appendix B would be an obviously meaningless gesture




> 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__"`.

+1



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

I hadn't thought about this irregularity if it appears within a class
definition. That aside, +1.



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

+1. Excellent!