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 <al...@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
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
