|Problems? Is your data what you think it is?
Re^4: Wassercrats::Improved Volume 0, Number 0by elusion (Curate)
|on Aug 26, 2004 at 22:08 UTC
I don't see how my use of globals is unsafe. If my use of eval could end up doing something dangerous because I'm improperly parsing the code before evaling it, please explain. I reviewed my code after you warned me about that, but I couldn't find a problem.It's not necessarily that globals are unsafe. But they are bad. The reason they're bad is they create state. This is something that you'll appreciate even more if you ever program in a functional language.
When debugging, it is far easier to deal with code that doesn't use globals. Because the minute globals enter the equation, you can no longer be sure what's changing what. What looked like good input has been changed somewhere, leaving you dazed and confused.
And it may not hit you that bad. But the moment someone tries to take over your code and maintain it, they will get lost. By using lexicals, you can keep track of what's getting changed where. Every time you put in a set of values, you will get the same set of values back out.
There are exceptions to this rule too. Database handles are often a good example. They don't have state (mostly). Using a database handle in one subroutine won't cause another subroutine to have different output.
I'm pretty sure I've said this to you before, but: you should stop arguing and start asking. Chances are, there are reasons that things are the way they are. Sometimes they're bad reasons, like "because that's the way they've always been". And in that case, you can often feel free to change them. But many times there are good reasons. And you should try to figure out what they are before you say things are dumb.