Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)

David Bruant bruant.d at
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 <mailto:erights at>>
>     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...
URL: <>

More information about the es-discuss mailing list