[[Invoke]] and implicit method calls

Tom Van Cutsem tomvc.be at gmail.com
Thu Sep 19 01:52:56 PDT 2013

2013/9/18 Till Schneidereit <tschneidereit at gmail.com>

> The fact remains that, without the invoke trap, proxy users have to get
> the information whether a method call is about to happen from other
> sources, even though the runtime would be perfectly able to provide it.
> Putting the call-if-defined wrinkle caused (or exposed) by other spec
> algorithms aside for a minute, I'd argue that not providing this
> information makes using proxies strictly more complex, and strictly less
> performant.

This is a good point.

> Taking that wrinkle into consideration again, I still think it might be
> handled by wrapping the "get function, call if get succeeded" steps used in
> some spec algorithms into an abstract operation. That operation could have
> a special case along the lines of "if the receiver is a proxy with an
> invoke trap, call that with the args list". That would mean that having an
> invoke trap causes all of these maybe-calls to be actual calls. Which seems
> ok to me.

I've been thinking about this and I don't think it's a good solution.

Take, for instance:

var target = {};
var proxy = new Proxy(target,  { } );
JSON.stringify(proxy); // conditionally invokes toJSON

Due to the current [[Get]]+[[Call]] behavior, the stringify call will check
whether target.toJSON is callable, which it isn't (it's undefined), so
stringify falls back to the default implementation (as it should).

Now, if a conditional invoke would always trigger a proxy's invoke() trap,
and the proxy would forward these calls, this will lead to a TypeError
(because the proxy tries to call target.toJSON()).

This hardly seems desirable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130919/a36ac314/attachment.html>

More information about the es-discuss mailing list