Invoke trap

David Bruant bruant.d at gmail.com
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. 
> Date.prototype.getTime.call(proxy) 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 
Map.prototype.set.call, no?

The issue for both proxiedMap.set() and 
Map.prototype.set.call(proxiedMap) 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

David


More information about the es-discuss mailing list