Action proxies

[David Bruant]

Le 05/02/2013 12:20, Tom Van Cutsem a écrit :
> 2013/2/4 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>
>     Le 04/02/2013 22:41, David Bruant a écrit :
>
>         Le 04/02/2013 19:57, Tom Van Cutsem a écrit :
>
>             The post-trap could be cached and reused, but only if the
>             post-processing is independent of the specific arguments
>             passed to the intercepted operation.
>
>         Is there any harm in passing the trap arguments to the
>         post-trap function additionally to the result?
>
>     I've played with post-traps a bit. A place I would naturally store
>     the post-trap to cache it is the handler.
>
>     Assuming trap arguments are passed to the post-trap, another idea
>     is to have pre and post traps. It duplicates the number of
>     elements in a handler, but not the size of the code (or marginally
>     assuming pre/post traps are longer than the boilerplate). Having a
>     post-trap would still be an opt-in, but the protocol to get it
>     would be "callable handler.[[Get]]" instead of the current
>     "callable pretrap-return". One allocation per handler would become
>     the natural default (while the current natural default is a
>     function literal as return value).
>
>
> I guess this could work. Borrowing naming conventions from Cocoa, you 
> could have an API along the lines of:
>
> willGetOwnPropertyDescriptor(target, ...args) // pre-notification
> didGetOwnPropertyDescriptor(target, result, ...args) // post-notification
> etc.
<bikeshed>
In most cases, posttraps aren't necessary. It may be a good idea to 
reflect this asymmetry in the handler API:
getOwnPropertyDescriptor(target, ...args) // pre-notification
didGetOwnPropertyDescriptor(target, result, ...args) // post-notification

Another idea:
     var handler = {
         getOwnPropertyDescriptor: {
             pre(target, ...args){
                 // ...
             },
             post(target, ...args){
                 // ...
             }
         },
         get(target, ...args){
             // ...
         }
     }

The "trap" (like getOwnPropertyDescriptor here) can expose 2 parts 
pre/post (which could as well be will/did). If the trap is callable 
(like get here), it's only the pretrap.

In an earlier message, I hadn't answered one of your points:
> I think the "on"-prefix is actually pretty important. It signals to 
> the proxy writer that the trap is a callback whose return value will 
> be ignored.
That's a distinction we're aware of as people who've followed the 
evolution of the API, but people discovering proxies will have to read 
the doc anyway to understand what they can do and how it works. I'm not 
sure the "on" (or any other) prefix will really help that much.
</bikeshed>

That just was my bikeshed-ish opinion. I won't fight if there is 
disagreement.

> I like the current API better because it allows for a cleaner pairing 
> of pre and post-traps, including the ability to share private 
> intermediate state through closure capture.
I have to admit, I'm a bit sad to loose that too. But that's the price 
to pay to get rid of invariant checks I think. It remains possible for 
pre/post trap to share info through the handler.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130205/be5317b1/attachment-0001.html>