B.3.1 The __proto__ pseudo property

Mark S. Miller erights at google.com
Tue May 7 14:04:34 PDT 2013


On Tue, May 7, 2013 at 1:59 PM, Mark S. Miller <erights at google.com> wrote:

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

My "since" is incorrect, as the functionality is available via
Object.setPrototypeOf. Nevertheless, I still think this would be a
meaningless gesture. OTOH, since it is meaningless, it is also mostly
harmless.



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



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


More information about the es-discuss mailing list