ES6 Proxy Function Call Trap

Tom Van Cutsem at
Thu Jun 11 19:01:48 UTC 2015


I sympathize with your point-of-view, but we've debated all the pros and
cons of `invoke` long ago, and unless new arguments are brought to the
table, I don't think it will be added again soon.

To clarify why the "invoke = get + call" equivalence is so important,
consider for instance the common coding pattern of a "conditional" method
call, where one only wants to invoke a method if it exists:

var foo =;
if (foo) {

With the current Proxy API, the `get` trap returns a function (or a proxy
for a function), and the code works fine regardless of whether foo() is
called as a method, or as a function.

With the addition of `invoke`, if you don't also provide a `get` trap, then
the code will not behave as expected. Likely `` will return
`undefined`, even though `` would have triggered the `invoke` trap
and done something useful.

So, *any* robust use of `invoke` still requires implementing a `get` trap
(to allow for all the use cases where methods are extracted as functions
from objects). As a result, it would lead to a net *increase* in

2015-06-11 15:48 GMT+02:00 Kevin Smith <zenparsing at>:
> Could a userland library make writing these kinds of proxies more
> ergonomic?

I don't see why not. The Proxy API offers only the bare minimum tools to
create your own custom "exotic" objects. Arguably we need to grow some good
libraries around it to make building these types of objects more routine
(although I'd be the first to point out that you should avoid "exotic"
objects unless there's a really compelling reason to go that route)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list