Invoke trap

David Bruant bruant.d at gmail.com
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 
> Map.prototype.set.call, 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 
membrane.

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 
Map.prototype.set.call(mapProxy) (same as before without the initial 
mapProxy.[[handler]].get)

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...

David


More information about the es-discuss mailing list