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).
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
