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

Yes, except:

a) proxies must then still allocate a temporary function object in the get
trap. Thus, the primary reason for having a derived trap (less
allocations), disappears.
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
status-quo.

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


More information about the es-discuss mailing list