in reply to Re: Ugly ways to declare global variables?
in thread Ugly ways to declare global variables?

There's an implied "that you can use" modifying phrase there that you're not using.

When you use "our" to declare a global variable under strictures, you are getting a "new variable out of it" that you can use. Without the "our" declaration (or the old "use vars" declaration), you cannot use the variable - the program does not run because of this. With the "our" declaration, you now can use the variable - it's syntactically as if it were a new variable. Which it mostly is - it's a new entry in the symbol table.

The fact that, under the covers, all that "our" does is set up a value in a global symbol table such that strict doesn't complain, is really not that important. That's just an implementation detail. The syntactical sugar of "our" is a huge level of abstraction that allows people to think they're getting a new variable, and, under strictures, not be too far off the real effect.

(++ for the uglier way to do it. Ewww! :-})

  • Comment on Re^2: Ugly ways to declare global variables?

Replies are listed 'Best First'.
Re^3: Ugly ways to declare global variables?
by Roy Johnson (Monsignor) on Apr 25, 2005 at 18:24 UTC
    you are getting a "new variable out of it" that you can use.
    There's nothing new about the variable, and that is important. It might already have a value. When you actually declare a variable, it's really new. It's fresh and unused from that point. When you specify our, you gain only the ability to use the variable without its package specifier. 
    #!perl
use strict;
use warnings;

$::z = 'bye';
our($z);
print $z, " is ", $::z, "\n";

    [download]
    Caution: Contents may have been coded under pressure.
[reply]
[d/l]
[select]

      When you actually declare a variable, it's really new. It's fresh and unused from that point.

      I'm having a hard time getting your point. Even if a declared variable starts out as "fresh and unused", the fact that it can be modified from anywhere else outside the package implies that this guarantee is meaningful only in very limited cases. An example will clarify what I mean: 

      # in Foo.pm
package Foo;
use strict;
use warnings;
use vars qw( $foo $bar );

$bar = 2;
our $baz;

sub print_out {
  ++$foo;
  ++$bar;
  ++$baz;
  print "\$foo: $foo\n\$bar: $bar\n\$baz: $baz\n";
}

1;


# in foo.pl
use strict;
use warnings;

package Foo; $Foo::foo = 7; $Foo::bar = 5; $Foo::baz = 8;
package main;
use Foo;
Foo::print_out();
__END__
% perl foo.pl
$foo: 8
$bar: 6
$baz: 9

      [download]
      It is true that, contrary to $baz, $foo and $bar are guaranteed to "start out" as being unused. Nonetheless, by the time they are actually used (e.g. in subs like print_out()) they has been modified from outside the package. So most of the code that uses $foo and $bar has no more assurance as to the purity of these variables than code that uses $baz has about its purity. Therefore, the fact that $foo and $bar start out in a pristine state strikes me as somewhat academic. So wonder if I am just missing some major aspect of the problem.

[reply]
[d/l]
        Whether it's a major aspect is debatable, but it is a point of confusion for some people who are not clear on all the concepts to have it look like a declaration when it's really just a pragma.
        Caution: Contents may have been coded under pressure.
[reply]

In Section Meditations