[[Invoke]] and implicit method calls

Tom Van Cutsem tomvc.be at gmail.com
Wed Sep 11 03:30:51 PDT 2013

2013/9/10 Allen Wirfs-Brock <allen at wirfs-brock.com>

> On Sep 10, 2013, at 10:48 AM, Till Schneidereit wrote:
> > Wasn't a major point in favor of having an [[Invoke]] trap that it
> wouldn't require returning a function from the trap at all? We'd lose this
> quality with both of these proposals.
> No, the major motivation was to provide a way to deal with different
> styles of |this| mapping that are needed for different styles of proxies.
>  However, the ability to implement a method code without producing a
> function is a desirable secondary benefit

That's not how I would characterize it.

Till's argument is the argument we had identified in favor of an invoke()
trap almost from day 1 of the Proxy proposal. It was offset by the desire
to keep the invoke = get+call invariant and to avoid non-extractable
callable properties. Much later, we figured invoke() was needed to allow
proxy handlers to cheaply rebind |this| when intercepting method calls.
This tipped the balance in favor of adding invoke(). But the idea of
avoiding the creation of a temporary function object is to me at least as

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

More information about the es-discuss mailing list