Eh, we should be careful how we define "globals" when making such statements. Indeed in strictly procedural programs it is foolish and unnecessary to have global variables. However, what about package globals? Having in Perl what would be denoted in other languages as a "static class member" is not an unreasonable thing to do, and is often in my experience necessary.

Those aren't globals. Those are static class members. That they are implemented as a package global is completely and utterly irrelevant. The same goes for any other CS construct you can think of that in Perl is implemented as a package- or file-scoped global. Truly global variables are good for three things only:
1. Hacking a one-off
2. Prototyping
3. Demonstrating how p00r yur skillz R

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Well clearly we are in fundamental agreement. At this point we are just arguing linguistic semantics.

Do you even know why this happens? Do you know if this happens outside mod_perl? Has this been an issue for you in programs you've written?

if it might be better in general to initialise each and every variable. So, instead of the above, we now have:

It is not an issue to me, but nonetheless I was interested to hear from the experts here what the normal practice is.

One of Perl's uniqueness is "there's more than one way to do it". I was curious to find out if there's indeed a preferred way of treating variables wrt value initialisation.