Tom Van Cutsem
tomvc.be at gmail.com
Tue Feb 5 03:20:43 PST 2013
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss