2013/9/18 Till Schneidereit <[email protected]>
> The fact remains that, without the invoke trap, proxy users have to get
> the information whether a method call is about to happen from other
> sources, even though the runtime would be perfectly able to provide it.
> Putting the call-if-defined wrinkle caused (or exposed) by other spec
> algorithms aside for a minute, I'd argue that not providing this
> information makes using proxies strictly more complex, and strictly less
> performant.
>
This is a good point.
> Taking that wrinkle into consideration again, I still think it might be
> handled by wrapping the "get function, call if get succeeded" steps used in
> some spec algorithms into an abstract operation. That operation could have
> a special case along the lines of "if the receiver is a proxy with an
> invoke trap, call that with the args list". That would mean that having an
> invoke trap causes all of these maybe-calls to be actual calls. Which seems
> ok to me.
>
I've been thinking about this and I don't think it's a good solution.
Take, for instance:
var target = {};
var proxy = new Proxy(target, { } );
JSON.stringify(proxy); // conditionally invokes toJSON
Due to the current [[Get]]+[[Call]] behavior, the stringify call will check
whether target.toJSON is callable, which it isn't (it's undefined), so
stringify falls back to the default implementation (as it should).
Now, if a conditional invoke would always trigger a proxy's invoke() trap,
and the proxy would forward these calls, this will lead to a TypeError
(because the proxy tries to call target.toJSON()).
This hardly seems desirable.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
