You are right that the example given is not one where a closure would be appropriate, which is why I pointed out the overhead of entering a function.
I think we may have different definitions of "closures". I think of a closure as a subroutine (anonymous or named) that captures the lexical scope of a variable, like the two anonymous divide routines in my code. The original code by Adam and your fix of it don't capture lexical scope; the values of $n are interpolated before eval ever sees it.
You seem to be talking about run-time compilation of new subroutines. While that can be a powerful technique, it is different than closures (to me, at least).
In reply to RE: RE (tilly) 3: Fly Subroutines on the Fly
by BlaisePascal
in thread Fly Subroutines on the Fly
by Adam
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |