in reply to problem with global variables going out of scope

...

my $showPUV = 0;

...

sub FilterMessage {
  ...
  our $showPUV;
  ...

[download]

Those are two different variables! The first is a lexical (my) variable, scoped to the file. The second is an alias to the package (our) variable $main::showPUV.

Solution 1 

my $showPUV = 0;

sub FilterMessage {
  ...
  if ( $showPUV ...
  ...

[download]

Noone outside of this file can access $showPUV. FilterMessage can since it's in the same file, even if it's called from another file.

Solution 2 

our $showPUV = 0;

sub FilterMessage {
  ...
  if ( $showPUV ...
  ...

[download]

Everyone can access $showPUV (altough other packages must use $main::showPUV). our $showPUV; is optional in FilterMessage, because the one at the top level is still in scope.

Update: Clarified by adding "an alias to".

Replies are listed 'Best First'.
Re^2: problem with global variables going out of scope
by acid06 (Friar) on Mar 28, 2006 at 21:12 UTC
    Those are two different variables! The first is a lexical (my) variable, scoped to the file. The second is the package (our) variable $main::showPUV.

    Just a side note really, but our variables are somewhat lexically scoped.
    Actual package scoped variables are declared with use vars.

    Actually, they're lexically scoped symbol table entries, since this is perfectly valid: 
    {
  our $var = 10;
  
  {
    package Other;
    our $var = 20;
    print "$var\n";
  }
  
  print "$var\n";

}

# no $var out here

    [download]
    But I think it's best not to do these sort of things.


    acid06
    perl -e "print pack('h*', 16369646), scalar reverse $="
[reply]
[d/l]
[select]

      I think of our as a lexically scoped directive similar to no strict 'vars'. The difference is that it only applies to the specified variables.

      You think of our as creating a lexically scoped variable which is aliased to a package variable.

      I don't agree with you. If the variable was lexically scoped, it wouldn't be possible to use it beyond the end of the lexical scope, as shown in the following code: 

      { our $var = 20; }
print("$var\n");  # 20

      [download]

      Update: Cleaned up my post.

[reply]
[d/l]
[select]
        I guess you're right.
        I didn't bother testing without use strict and this could would fail if it was in effect.

        However, this might be considered either a perl bug or a documentation glitch as perlfunc reads:

        "our" associates a simple name with a package variable in the current package for use within the current scope. When "use strict 'vars'" is in effect, "our" lets you use declared global variables without qualifying them with package names, within the lexical scope of the "our" declaration. In this way "our" differs from "use vars", which is package scoped.

        Unlike "my", which both allocates storage for a variable and associates a simple name with that storage for use within the current scope, "our" associates a simple name with a package variable in the current package, for use within the current scope. In other words, "our" has the same scoping rules as "my", but does not necessarily create a variable.


        acid06
        perl -e "print pack('h*', 16369646), scalar reverse $="
[reply]
[d/l]

In Section Seekers of Perl Wisdom