ES6 Proxy Function Call Trap

Isiah Meadows impinball at
Fri Jun 12 06:37:17 UTC 2015

To be honest, you could simply subclass Proxy to add an invoke hook, if
it's that simple:

function makeHandler(handler) {
  let {get, invoke} = handler;
  let lastGet = false;
  let opts = {};
    .filter(key => key !== 'get' && key !== 'call')
    .map(key => [key, handler[key]])
    .forEach(([key, func]) =>
        opts[key] = function () {
      lastGet = false;
      func.apply(this, arguments);
  opts.get = function (target, property) {
    new Proxy(target[property], {
      apply(f, thisArg, args) {
        return, target, property, args);
    return get.apply(this, arguments);
  return opts;

class InvokeProxy extends Proxy {
  constructor(target, handler) {
    super(target, makeHandler(handler));

  static revocable(target, handler) {
    return Proxy.revocable(target, makeHandler(handler));

---------- Forwarded message ----------

  From: Tom Van Cutsem < at>
To: Kevin Smith <zenparsing at>
Cc: es-discuss <es-discuss at>
Date: Thu, 11 Jun 2015 21:01:48 +0200
Subject: Re: ES6 Proxy Function Call Trap


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

 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