ES6 Proxy Function Call Trap

Tom Van Cutsem at
Tue Jun 9 19:33:54 UTC 2015


The "call" trap you suggest has been suggested numerous times before (by
the name of the "invoke" trap) and was nearly added to the spec at one
point, but eventually removed because of a number of reasons, the more
important one being that it breaks the equivalence that a method call in JS
is nothing but a property access followed by a function call.

The suggestion made by Claude has nothing to do with Reflect, and you don't
necessarily need Reflect to implement it: |Reflect.apply(fun, thisArg,
args)| is equivalent to |, thisArg,
args)|, it's just shorter and more idiomatic.

The important thing is to return, from your `get` trap, another Proxy that
implements the `apply` trap to be able to intercept the subsequent method


2015-06-09 17:25 GMT+02:00 Jason Orendorff <jason.orendorff at>:

> On Tue, Jun 9, 2015 at 3:44 AM, Edwin Reynoso <eorroe at> wrote:
> > Alright first I'll say I'm using FF to test because FF supports proxies,
> and
> > I really don't know how to use Reflect and how it works yet. FF as well
> does
> > not support Reflect right now. Therefore I'll look into that.
> That's right. Reflect is a key tool when you're writing proxy
> handlers. I'm working on implementing it in Firefox now. If you like,
> you can subscribe to this bug and get updates (quiet so far):
> Here, I think the technique you're looking for might be that the proxy
> handler's get() method should return a new proxy (representing an
> array of methods). This new "method proxy" needs something callable as
> its target. When the method proxy's .call() trap is called, it'll
> receive the arguments.
> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list