Le 02/12/2012 20:40, Tom Van Cutsem a écrit :
2012/12/2 Mark S. Miller <[email protected] <mailto:[email protected]>>
I think we can rescue around wrapping. I'll call this approach "opaque
around wrapping". The idea is that the proxy passes into the handler
trap a proxy-generated no-argument function (a thunk) called "action".
Interesting. I had thought of a similar approach, but hadn't pursued
it because I thought allocating a thunk per trap invocation would be
deemed too expensive. I'll go ahead and sketch the design, which I
think corresponds closely with your approach B)
I think that for most traps, "action" could be a deeply frozen wrapped
version of Reflect.trap. It would reduce "action" functions to one per
trap which would be much better than one per trap invocation.
4) are there any return values from the trap that the proxy would pay
attention to?
Yes. If the trap returns the original result, it doesn't do any extra
checks. Otherwise it does.
Said a bit differently, the extra check is reduced to the equality
between the return value of "action" and trap return value.
I prefer #A to #B as it gains the full benefits of simplifying the
overall spec and implementation. However, #B still seems better than
current direct proxies, as the normal case gets target-maintenance and
invariant checking for free.
I agree that #B doesn't really simplify anything in the spec (the
invariant checks are still there sometimes).
I'm not sure if it is inherently better than the current design
though: we gain performance in terms of avoiding invariant checks, but
we lose performance by having to allocate a per-call thunk, + the API
becomes more complex (an additional parameter to every trap)
I do think that passing an action or "forward()" thunk to a trap as
extra argument beats David's proposed "throw ForwardToTarget" trick in
terms of elegance and usability (maybe not in terms of performance).
I agree it looks less hacky. But I'm not entirely convinced when it
comes to usability. As mentioned in the other answer, it makes
understanding the trap a bit harder because what comes out of the trap
may be less clear: since there is no explicit return statement, one has
to figure out, what the value of the "action" function specifically when
it's called for the "around" case.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
