Consider using eval for function composers

[mstade]

variadic and other functions return a wrapper, which has a different signature than the underlying function. This can get confusing in debugging, since it effectively hides the underlying in stacks and variable slots. It would be nice if these functions would be able to copy the signature where appropriate, or otherwise retain as much crucial information as possible – such as the name and argument list. This doesn't necessarily apply to all composers, but certainly to things such as variadic which really just changes the meaning of the last parameter.

A concern with this is that the use of eval is fraught with cargo culture induced FUD, and so is frowned upon by essentially everyone – including myself.

So I'm opening this issue as a means of clearing up some of the mystery surrounding this particularly useful construct, since it enables some pretty interesting meta programming capabilities. First, here's a performance test comparing the execution performance of a function wrapped by eval, and one wrapped by a regular function literal:

http://jsperf.com/eval-wrapping

Running this on Aurora, I get a virtually non-existant performance difference between the two, with eval coming out on top no less, suggesting that at least in this kind of context (which is equivalent to that of variadic, btw) performance is not a real concern.

Other things to explore is how this affects stack traces and debugging capabilities. My gut feeling, from having read some articles regarding this specific thing, is that debugging evaluated code is tricky, but that modern engines do a pretty bang up job. What's important to note though, is that the main context where eval would be used in funkis is to wrap other functions. This means that the code that is evaluated is largely insignificant, and if debuggers just step right through that code it's even better, since the wrapper code is pretty much useless debug data anyway.

[mstade]

(As a side note, I'm somewhat dismayed that the factorial function in the test only yields ~50k ops/sec in FF Aurora.)

[mstade]

Updated the performance test to include trivial as well as non-trivial functions being wrapped. This is to try to make sure engines don't just optimize away the function calls altogether. The results from modern browser engines suggest there's little if any difference, regardless. I think the performance question is settled.

[mstade]

So after reviewing the tests some, it seems the eval version is consistently slower in Firefox, by about ~15-20%. This is considerable, however in the grand scheme of things I think that's acceptable since it has the potential to significantly improve stack traces and other diagnostics. As well, other browsers such as Chrome and Safari does not show any meaningful differences in execution speed, regardless of whether the function being wrapped is trivial or non-trivial. Because this slowdown isn't across the board I reckon it's not worth caring about just because Firefox isn't sufficiently optimized.

[mstade]

Consider the Closure compiler restrictions when deciding on this issue. Using eval makes it trickier to perform static analysis and thus may preclude some potential optimizations by tooling.