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

David Bruant bruant.d at gmail.com
Sun Dec 2 15:06:01 PST 2012


Le 02/12/2012 18:34, Mark S. Miller a écrit :
> On Sun, Dec 2, 2012 at 8:40 AM, Tom Van Cutsem <tomvc.be at gmail.com> 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


More information about the es-discuss mailing list