[[Invoke]] and implicit method calls

Brendan Eich brendan at mozilla.com
Fri Sep 13 12:43:51 PDT 2013


> Tom Van Cutsem <mailto:tomvc.be at gmail.com>
> September 13, 2013 6:36 PM
> MarkM and I talked about conditional invocation offline and we 
> convinced ourselves to argue for the status-quo (i.e. continue to 
> encode conditional invocations as [[Get]]+[[Call]]).
>
> The most compelling argument we can think of is that [[Get]]+[[Call]] 
> is also the pattern JavaScript programmers use to express conditional 
> method calls today:
>
> var f = obj[name];
> if (f) { f.call(…); } else { … }
>
> No matter whether or how we extend the MOP, such code exists and will 
> continue to exist, and well-designed proxies that want to re-bind 
> |this| must already deal with this pattern by implementing the "get" 
> trap correctly.

Whew. Thanks.

> We already have distinct "get" and "invoke" traps. Proxy writers must 
> already understand the dependency between these traps. Let's not make 
> things more complicated by adding a third, or by unnecessarily 
> complicating the signature of "invoke".

Or by adding boolean parameters if we can avoid 'em.

> Given the status-quo, a proxy that wants to rebind |this| to the 
> target object must do so by overriding both "get" and "invoke". In the 
> "invoke" trap, |this|-rebinding is cheap (i.e. no need for bound 
> functions). In the "get" trap, it requires the handler to return a 
> bound function (which costs).

Right! JS has first-class functions, any memoizing vs. recreating is up 
to the object, but some function must be found or created that binds the 
right |this|.

> But the cost will not be paid for ordinary method calls, which are 
> expected to be the common case.

Thanks again, to you and Mark.

/be


More information about the es-discuss mailing list