Invoke trap

Tom Van Cutsem tomvc.be at gmail.com
Mon Jun 10 00:47:40 PDT 2013


2013/6/9 David Bruant <bruant.d at gmail.com>

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

Yes, that's what I meant.


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

Indeed. The point is that membranes wrap the built-in functions so that
they do the proper unwrapping.


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


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:

proxiedDate.getTime() // works because "invoke" trap can efficiently rebind
|this| from proxiedDate to the real Date instance when forwarding

The invoke() trap does not come into play for dot-called methods, so the
following remains non-transparent:

Date.prototype.getTime.call(proxiedDate) // error: not a Date

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130610/24a08a0b/attachment.html>


More information about the es-discuss mailing list