nested functions

[Duncan Booth]

Georg Brandl wrote:

> That's right. However, if the outer function is only called a few times
> and the nested function is called a lot, the locals lookup for the
> function name is theoretically faster than the globals lookup. Also,
> in methods you can use closures, so you don't have to pass, for example,
> self to the inner function.

If you are worried about the overhead of looking up the function name in 
the local rather than global scope then you should also worry about the 
overhead of accessing self through a closure rather than as a parameter.

As always in these cases, don't worry about it until you know definitely 
(by timing) that performance is an issue in that part of your code, and 
then time the different options and refuse the temptation to guess as you 
will probably get it wrong. The relative times here will depend on a lot of 
factors, such as how often you access the closure/parameter, and whether or 
not there are other arguments to the function.

I frequently nest functions, but I do it in cases where I want to simplify 
a function body and don't see any case for creating yet another generally 
accessible method or function.

Some benefits of nested functions: you can use a function name which is 
short by self-explanatory within the context of the outer function without 
having to worry about it conflicting with other function/variable names. 

The extracted functions are kept close to the place where they are used: a 
small support function which is a few hundred lines away from where it 
is used is more accident prone than one right next to the place it is used. 
Also, if you later refactor out the main method the support functions will 
disappear as well rather than lying around unused.

You can use closures, not because you have to, but because it simplifies 
the calls and therefore keeps expressions simpler and easier to read.

Of course you can also mess things up totally by overdoing it.