B.3.1 The __proto__ pseudo property

Axel Rauschmayer axel at rauschma.de
Tue May 7 20:46:09 PDT 2013

Looks like a very clean solution. The only thing I’m not entirely convinced about is Object.setPrototypeOf()...

... given how one is normally discouraged from using such functionality (=__proto__ as a setter) and
... given that the most frequent use case goes away in ES6 (thanks to it allowing one to subclass built-ins).

Hence, honest question: Does it make sense to expose a new API for something that is mainly used for hacks? If you really needed it, you could retrieve it like this:

const mySetPrototypeOf = Object.getOwnPropertyDescriptor(Object.prototype, '__proto__').set;
// mySetPrototypeOf.call(obj, aProto);
// Alternatively: mySetPrototypeOf = Function.prototype.call.bind(...)

On May 7, 2013, at 22:57 , Allen Wirfs-Brock <allen at wirfs-brock.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.  
> 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.

Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

More information about the es-discuss mailing list