<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/6/9 David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 09/06/2013 12:50, David Bruant a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Le 09/06/2013 11:37, Tom Van Cutsem a écrit :<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For full transparency across isolated object graphs, I think membranes are still the way to go.<br>
</blockquote><div class="im">
I don't understand that part. A membrane (with shadow targets?) will have the same problem as a proxy alone when it comes to Map.prototype.set.call, no?<br>
</div></blockquote>
I think I understand what you meant. I think you meant that the outside of the membrane never interacts with built-ins on membrane objects, but rather on membrane-wrapped versions of the built-ins; the actual built-in acting on the actual Map or actual Date happens inside the membrane.<br>
</blockquote><div><br></div><div style>Yes, that's what I meant.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If that's what you meant, I feel that it equally applies to method invocation. That is, if you have a wrapped map, it has a wrapped Map.prototype and<br>
    mapProxy.set(x, y)<br>
<br>
calls mapProxy.[[handler]].get which returns the wrapped 'set' method. This wrapped 'set' method has its 'apply' trap called. In the apply trap, the target is the actual Map.prototype.set, thisArg is a wrapped map. the apply trap has access to some wrapped->unwrap weakmap and can apply the built-in set to the built-in map.<br>

The equivalent demonstration can be made with Map.prototype.set.call(<u></u>mapProxy) (same as before without the initial mapProxy.[[handler]].get)<br></blockquote><div><br></div><div style>Indeed. The point is that membranes wrap the built-in functions so that they do the proper unwrapping.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My point is that the invoke trap doesn't add something to the isolated graph use case.<br>
For the non-membrane proxy use case... I don't know what to think anymore...</blockquote><div><br></div><div style>Yes, and I already agreed to that upstream: the only thing that invoke() adds is that it makes it easy and efficient to get the common case right:</div>
<div style><br></div><div style>proxiedDate.getTime() // works because "invoke" trap can efficiently rebind |this| from proxiedDate to the real Date instance when forwarding</div><div style><br></div><div style>
The invoke() trap does not come into play for dot-called methods, so the following remains non-transparent:</div><div style><br></div><div style>Date.prototype.getTime.call(proxiedDate) // error: not a Date</div><div style>
<br></div><div style>Cheers,</div><div style>Tom</div></div></div></div>