Invoke trap

David Bruant bruant.d at
Sun Jun 9 11:28:06 PDT 2013

Le 09/06/2013 12:50, David Bruant a écrit :
> Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
>> For full transparency across isolated object graphs, I think 
>> membranes are still the way to go.
> I don't understand that part. A membrane (with shadow targets?) will 
> have the same problem as a proxy alone when it comes to 
>, no?
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 

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
     mapProxy.set(x, y)

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.
The equivalent demonstration can be made with (same as before without the initial 

My point is that the invoke trap doesn't add something to the isolated 
graph use case.
For the non-membrane proxy use case... I don't know what to think anymore...


More information about the es-discuss mailing list