[[Invoke]] and implicit method calls
till at tillschneidereit.net
Mon Sep 23 04:19:53 PDT 2013
On Mon, Sep 23, 2013 at 10:33 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> Indeed, there are trade-offs and there is no silver bullet.
> The status-quo, which I advocated, entails:
> - we keep the invoke() trap, with its current signature: invoke(target,
> propertyName, argsArray, receiver)
> - conditional method calls in the spec are still expressed as [[Get]] +
> [[Call]], following the common JS idiom
> After your comments, I would add:
> - we change ForwardingHandler.get to automatically re-bind |this| by
> wrapping function-valued data properties of its target
> The only drawback of the status-quo, that I see, is that proxies that do
> not subclass ForwardingHandler must exercise more care in their "get" trap
> if they want to intercept the this-binding. Most other alternatives make it
> easier for proxy authors to avoid this issue, but at the expense of making
> the JS MOP strictly more complex/less intuitive.
FWIW, the arguments in favor of keeping the status quo as described by Tom
have convinced me.
The issue triggering this entire thread is that some spec algorithms don't
use [[Invoke]], so the .invoke trap isn't triggered for them. I'm now
convinced that seeing that as an issue is ascribing too much power to the
.invoke trap. Let's state its behavior this way: "the .invoke trap is
triggered by direct method calls on the proxy object in the form of
`proxy.method()` or `proxy["method"]()`. It is not triggered by invocations
of a function that was extracted from a proxy object." It makes a lot of
sense that there might be spec algorithms (just as other code that might
use the proxy object) that call functions *after* extracting them from
their receiver. Which goes to show that properly implementing proxies isn't
easy, not that the .invoke trap is somehow broken.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss