Action proxies

[Tom Van Cutsem]

2013/2/4 David Bruant <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.

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. However, if the allocation cost of the
closure is a deal-breaker, the above API would be one way to avoid that
cost.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130205/eed0edd2/attachment.html>