Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re^2: OUR declaration

by nobull (Friar)
on Sep 24, 2006 at 13:03 UTC ( #574597=note: print w/replies, xml ) Need Help??

in reply to Re: OUR declaration
in thread OUR declaration

When using our as an alternative to my in pseudo-CGI scripts that'll be running under mod_perl I recommend getting into the habit of using local our so that you get a pseudo "global destruction" at the end of the pseudo-CGI script.

Otherwise, if the declaration doesn't initialise, the value from a previous execution of the script may persist and also if there are any destruction side effects (like closing files) these may get deferred.

Replies are listed 'Best First'.
Re^3: OUR declaration
by perrin (Chancellor) on Sep 25, 2006 at 03:57 UTC
    I don't reccommend using our "as an alternative to my" under mod_perl. They don't do the same thing, and mod_perl doesn't change that. If you are using "our" because your code has unintentional closures around "my" variables that showed up when you used mod_perl, you should really change your code to fix this problem. It can bite you in other ways, and "local our" is a pretty nasty construct.
      The mod_perl Reference recommends exactly that.

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

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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://574597]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2023-06-01 16:30 GMT
Find Nodes?
    Voting Booth?

    No recent polls found