Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)
bruant.d at gmail.com
Sun Dec 2 15:30:24 PST 2012
Le 02/12/2012 20:40, Tom Van Cutsem a écrit :
> 2012/12/2 Mark S. Miller <erights at google.com <mailto:erights at google.com>>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss