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
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
More information about the es-discuss