[[Invoke]] and implicit method calls

Jason Orendorff jason.orendorff at gmail.com
Tue Sep 17 06:36:15 PDT 2013

On Fri, Sep 13, 2013 at 11:36 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 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.

Tom, it seems to me if there’s such a thing as “implementing the "get"
trap correctly”, i.e. such that method calls work, that removes the
main motivation for having [[Invoke]] in the first place. To recap
what else [[Invoke]] achieves, in the light of that:

* improved performance for proxies, because method calls go through
one proxy handler trap rather than two, and no temporary function
object is allocated

* proxies can observe a bit about the caller (whether or not it's an
[[Invoke]] call site), when a method is called

If that's all, it seems like we should definitely remove [[Invoke]]
and the .invoke trap. The MOP was already complicated enough. The
performance argument is a non-starter, and the other “feature” is
entirely undesirable.


More information about the es-discuss mailing list