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

Tom Van Cutsem at
Mon Nov 26 11:59:30 PST 2012

2012/11/26 David Bruant <bruant.d at>

> Le 25/11/2012 12:44, Tom Van Cutsem a écrit :
> I think there might be a loss in expressiveness if forwarding to the
> target throws an error. With current proxies, the trap can catch this
> exception; with notification proxies, the error is thrown after the trap,
> so it can't.
> Now, it would require an in-depth analysis, but I intuit that all cases
> where an internal operation throws have a corresponding invariant checks
> (which errors aren't caught by current proxies). If that was the case, it
> would mean that there is actually no loss (or a minor loss consisting in
> loosing the ability to catch an error and rethrow it yourself)

No, there is a loss. E.g. calling Reflect.get or Reflect.set on the target
may throw arbitrary exceptions, not only exceptions related to broken
invariants. With direct proxies, it's easy to write a "silencer" proxy that
eats all exceptions. Can't do that with notification proxies. (Not saying
such a silencer is a useful abstraction, but we're talking absolute
expressiveness here, so it counts.)

More generally, notification proxies simplify "before"-style wrapping (e.g.
revocable references become a breeze to implement), but they complicate
"after" and "around" style wrapping. For instance, how would one implement
a logging proxy that wants to log the *result* of forwarded operations?
(forwarding the operation twice is cheating)

> Also, if you can only forward to target, there is no way you can define
> custom property descriptor attributes which would be a shame in my opinion.

Right, I hadn't noticed that. Good point.

We could define a symbolic value (like StopIteration for iterators) that
> would mean "forward to target". By essence of what forwarding to the target
> means, there would be no need to perform the least invariant check. We can
> call it ForwardToTarget :-)

I think we've previously entertained a similar proposal when a handler was
encountering the .public property of a private property it didn't know, and
then wanted to signal to the proxy "I don't know this private name, please
forward". I recall one issue was that you'd really want a unique token per
trap invocation, which costs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list