Le 02/12/2012 18:34, Mark S. Miller a écrit :
On Sun, Dec 2, 2012 at 8:40 AM, Tom Van Cutsem <[email protected]> wrote:
- "after"-style wrapping allows you to get notified of an operation
after-the-fact. Depending on the API, the "after"-wrapper may or may not get
to see the outcome of the operation, and may or may not change the final
outcome passed on to clients.
- "around"-style wrapping is the most general and allows the composer to
decide if and when to forward, and what result to return. It subsumes
before/after wrapping. This is what direct proxies currently provide.

It does not subsume before/after wrapping, because it loses the integrity
of before/after (e.g., the wrapper can lie and cheat, where the before and
after cannot).  That may be worth it, but it is substantially different.

You're right, around doesn't subsume before+after in that regard. Thanks for
clarifying.
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".
The normal case is that the trap does stuff before calling action,
calls action with no arguments and ignoring action's results, does
stuff after action, and returns nothing.
The point of "around" is to do something with the result in the middle of the trap, isn't it? For question 3, I'd answer that the "action" should return the result.

The call to action performs
the original operation on target and remembers the result. After the
trap returns, the proxy returns the remembered result of action.
    target = {a:1};
    var p = new Proxy(target, {
        get: function(target, name, action){
            var v = action();
            target[name] = 2;
        }
    })

    p.a; // ?

If p.a is 1 because the call to "action" remembered the "1", then the target and the proxy look awkwardly desynchronized. To know what's being returned from the trap, one needs to remember when the action is being called which makes writing traps harder I feel. With the current design, looking at the return statements is enough. If p.a is 2, I don't understand the point of "action". Or at least, I don't see how it's better than just calling Reflect[trap].

1) what happens if the trap does not call action?
If calling action was made compulsory, then, it would have the same downsides than the notification proxies when it comes like virtual objects including the necessity of a physical backing.

David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to