Le 11/09/2013 06:10, Boris Zbarsky a écrit :
> Hey all,
>
> I was looking at implementing a membrane using ES6 proxies and ran 
> into a snag.  Consider a situation where object A has prototype B.  A' 
> is a proxy implementing the membrane, whose target is A.
>
> But now if Object.getPrototypeOf(A') is invoked the return value will 
> be B (unless it just throws).  There's no way for A' to return a new 
> proxy B' whose target is B in this situation.
In essence yes. In practice, you can do:
     // trap:
     getPrototypeOf: function(target){
         target.__proto__ = B';
         return B';
     }
But of course, it changes A [[Prototype]], which is probably not 
desirable. And of course, although to-be-standard, __proto__ is bad taste...

I think it was discussed at some point to get rid of the restriction on 
the getPrototypeOf trap and enforce it only for non-extensible objects 
(but I can't find the info anymore, I might just be inventing this...). 
It would allow you to return a different object assuming the target is 
and remains extensible (more on that below).

> Is the intent here that the membrane should not be using A as its 
> target but some third object A''?
It depends, but in some cases yes and A'' is then called a "shadow target".
It depends on what sort of membrane you want. See Tom's May 2013 TC39 
meeting slides (starting slide 22 for membranes):
http://soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/Notification%20Proxies-TC39-May-2013.pdf

You need a shadow target if code running against the membrane wants to 
perform actions that require eternal invariants enforcement [1], so 
typically call Object.preventExtensions, or make some properties 
non-configurable. And also that you don't want these invariants to be 
enforced on the actual proxy targets. If you're cool with code running 
against the membrane to enforce these invariants on objects under your 
control, you don't need shadow targets.

David

Ps: btw, wasn't "GetInheritance" supposed to be renamed "GetPrototype"?

[1] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html

Le 11/09/2013 06:10, Boris Zbarsky a écrit :

> But now if Object.getPrototypeOf(A') is invoked the return value will 
> be B (unless it just throws).  There's no way for A' to return a new 
> proxy B' whose target is B in this situation.

In essence yes. In practice, you can do:

     // trap:
     getPrototypeOf: function(target){
         target.__proto__ = B';
         return B';
     }

But of course, it changes A [[Prototype]], which is probably not 
desirable. And of course, although to-be-standard, `__proto__` is bad taste...

I think it was discussed at some point to get rid of the restriction on 
the getPrototypeOf trap and enforce it only for non-extensible objects 
(but I can't find the info anymore, I might just be inventing this...). 
It would allow you to return a different object assuming the target is 
and remains extensible (more on that below).

> Is the intent here that the membrane should not be using A as its 
> target but some third object A''?

It depends, but in some cases yes and A'' is then called a "shadow target".
It depends on what sort of membrane you want. See [Tom's May 2013 TC39 
meeting slides](http://soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/Notification%20Proxies-TC39-May-2013.pdf) (starting slide 22 for membranes).

You need a shadow target if code running against the membrane wants to 
perform actions that require eternal invariants enforcement [1], so 
typically call Object.preventExtensions, or make some properties 
non-configurable. And also that you don't want these invariants to be 
enforced on the actual proxy targets. If you're cool with code running 
against the membrane to enforce these invariants on objects under your 
control, you don't need shadow targets.

Ps: btw, wasn't "GetInheritance" supposed to be renamed "GetPrototype"?

[1]: https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html