bruant.d at gmail.com
Mon Feb 4 14:05:07 PST 2013
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).
More information about the es-discuss