While there are differences between using my and our for global variables, in my experience they don't come into play in most scripts unless they're run under something which turns all your subroutines into inner subroutine, like mod_perl. That's why I suggested using our for global variables, since it works the same in both scenarios.

My understanding is the our was a right and proper way to declare package globals.

Are there problems you're aware of with using our for package globals under mod_perl or anywhere else?

I'll bring this up on the mod_perl dev list. I don't think we should advise people to use such a crazy construct.

The problems people encounter with ModPerl::Registry are usually not caused by inner subroutines, but rather by closures. The closures were always there, but were never noticed before in a non-persistent environment. Consider this:

my $q = CGI->new;
show_name();

sub show_name {
    print $q->param('name');
}
[download]

This code will break when run in mod_perl because it forms a closure around $q, making it a private variable for the show_name() sub after compilation.

This problem can be fixed by making $q an our variable, but that's a poor programming practice, giving $q a large scope and persistence that it should not have. The correct fix is to pass the variables that the sub requires:

my $q = CGI->new;
show_name($q);

sub show_name {
    my $q = shift;
    print $q->param('name');
}
[download]

Replacing my $q with local our $q would give $q neither a larger scope nor a greater persistance, and would also solve the problem.