Re^5: OUR declaration

[perrin]

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');
}

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');
}

[ikegami]

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

[perrin]

Sure it does. The $q created here is persistent and is part of the symbol table. It will get reset to the value it had before the local was applied to it at the end of the file, but it's still a global variable. Are you really saying you don't think passing variables to subs is a cleaner solution?

[ikegami]

If you think my variables are freed, you're wrong. Neither the variable (on the pad) nor the SV assigned to it are freed at the end of the function.

Are you really saying you don't think passing variables to subs is a cleaner solution?

I agree that the number of global variables should be limited, and I find few reason to use them. However, the author thought it acceptable and/or desirable for $q to be a global variable, so I just pointed out a way to make that possible.