I object to that "easier" approach because it confuses the intent of the code; data which should be hidden from the rest of the program is revealed when you use global state this way.
Update: Re^3: Is modifying the symbol table to redefine subroutines evil?
A function is a piece of code lumped together to serve some purpose; the function name represents this purpose in your code. I've been influenced heavily by functional programming, but I think that programs are the most readable when functions "do the same thing" with respect to the rest of the program each time they are called; that way, when reading code you don't have to maintain a lot of state in your head to predict behavior.
There are two possibilities for the "evil" code:
- The first call and the subsequent call "do different things" with respect to the rest of the program, in which case they should NOT be done by the same function. Two different tasks, two different functions.
- The first and subsequent calls "do the same thing" with respect to the rest of the program. For example, Re: Is modifying the symbol table to redefine subroutines evil? shows a function which seems to do the same thing each time from outside the function, but uses the "evil" construct. In this case, putting them both in the same function is appropriate, but your solution of having global state means that you have some information which is not useful to you and which should really be hidden from the rest of the program (since all calls "do the same thing").
suggests using a lexical closure. That seems fine to me too, I just don't like the globals much.