[[Invoke]] and implicit method calls
Tom Van Cutsem
tomvc.be at gmail.com
Sat Sep 21 02:53:21 PDT 2013
2013/9/21 Allen Wirfs-Brock <allen at wirfs-brock.com>
> On Sep 20, 2013, at 5:31 PM, Brendan Eich wrote:
> > Given this, having the legacy internal calls continue to use get+call
> seems fine to me. A proxy implementing toString, e.g., can make it work
> using these traps just as well as via get+invoke, and without double lookup
> or boolean-trap-smelling (id | func) parameterization of invoke.
> In that case, why not just use [[Get]]+[[InvokeFunction]] in all cases
> (including obj.m(()) and not have the current [[Invoke]] at all. It allows
> the proxy handler to correctly intercede on all method invocations
> including conditional cones.
a) proxies must then still allocate a temporary function object in the get
trap. Thus, the primary reason for having a derived trap (less
b) every method call on a proxy triggers at least 2 traps ("get" +
"invoke"). Another selling point of invoke() was that method calls go
through one trap only.
c) double-lifting needs 2 traps (get + invoke) rather than just get.
At that point, we're better off dropping [[InvokeFunction]] entirely.
As Brendan mentioned, methods are extractable in JS. A new MOP operation
doesn't relieve proxies from honoring that contract.
I believe we made the right trade-offs so far and still stand by the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss