[[Invoke]] vs [[Get]]

Tom Van Cutsem tomvc.be at gmail.com
Sun Jun 9 08:13:43 PDT 2013

2013/6/8 Till Schneidereit <tschneidereit at gmail.com>

> At the last TC39 meeting, an agreement was reached for proxies to support
> an Invoke trap. I'm currently implementing this trap in SpiderMonkey[1] and
> realized that there's one conceptual issue that has to be decided in the
> spec:
> Currently, the [[Get]] trap naturally handles method calls on the proxies,
> as these are gets followed by calls to the returned function value. With
> proxies also being able to trap [[Invoke]], things become less clear, with
> four possible options:
> 1. for method calls, only the [[Invoke]] trap is called
> 2. if an [[Invoke]] handler exists, it is called, otherwise a [[Get]]
> handler is called, if that exists
> 3. like 2., but additionally, if the [[Invoke]] handler doesn't return a
> callable value, the [[Get]] handler is called
> 4. like 3., but with reserved order of handler invocation: if a [[Get]]
> handler exists, it is called. If the result isn't callable, or [[Get]]
> isn't handled, an [[Invoke]] handler is called, if one exists

I would strongly advocate position 1: for method calls, only call
[[Invoke]]. This is most consistent with the current API design.

> The first of these options seems conceptually cleanest to me, but I do
> think that the other options (perhaps except for the last one) can be
> argued for to some extend, too: the abstract operation `Invoke`, via its
> step 5, `GetMethod`, contains a call to the [[Get]] operation, after all.

Agreed, it is sometimes useful to have one trap depend on another. That's
why we proposed the DelegatingHandler [1]. The DelegatingHandler's default
implementation for invoke would call the [[Get]] trap. See the
non-normative self-hosted implementation of DelegatingHandler for one
possible implementation.

[1] http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130609/a25fb5b8/attachment.html>

More information about the es-discuss mailing list