Invoke trap

David Bruant bruant.d at
Sun Jun 9 09:50:40 PDT 2013

Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
> I think your analysis is mostly right: if we want to make e.g. 
> work, then the easiest way to fit 
> that into the current design would be to add Date-specific traps (and 
> Map-specific, Set-specific, Regexp-specific, etc. traps)
> The question is whether there's a strong need for intercepting these 
> operations. It implies a pretty strong growth of the handler API. And 
> it's not sufficiently general-purpose to also work for exotics that 
> are defined outside of ES6 (e.g. DOM objects).
I can live with DOM objects not being fully transparent (since they were 
designed a while ago without proxies in mind). If it were too 
complicated because they're legacy, Date and RegExp could be given up on 
too (I think they're doable though), but I feel all other ES6 objects 
should be fully transparent. They have no good reason not too.

> For full transparency across isolated object graphs, I think membranes 
> are still the way to go.
I don't understand that part. A membrane (with shadow targets?) will 
have the same problem as a proxy alone when it comes to, no?

The issue for both proxiedMap.set() and is that the internal 'set' algorithm 
wants to play with an internal field which can't be accessed. This 
applies to a bound functions too, I believe:

     var boundHas = Set.prototype.has.bind(proxiedSet)
     boundHas(); // throw TypeError


More information about the es-discuss mailing list