Re: 'our' is not 'my'

[ikegami]

in reply to 'our' is not 'my'

There is a catch with our that doesn't exist with use vars:

package AA;
$AA::var = __PACKAGE__;
our $var;
print "$var\n";

package BB;
$BB::var = __PACKAGE__;
print "$var\n";         # Prints 'AA'.

Using curlies when using multiple packages in one file avoids the problem.

{
   package AA;
   $AA::var = __PACKAGE__;
   our $var;
   print "$var\n";
}

{
   package BB;
   $BB::var = __PACKAGE__;
   print "$var\n";         # Compile error!
}

Keeping that exception in mind, our is like no strict 'vars'; on a per-var basis.

[ruzam]

In your first example, how is it that 'our $var;' in package AA makes $var available to both package BB and package main? Why does package BB fall back to AA's result without any kind of warning?

[ikegami]

I prefer to think of our as the equivalent of no strict 'vars' for a single variable, but in reality, our creates a lexically-scoped variable aliased to a package variable.

In effect,
our $var;
is the same as
use Data::Alias;
alias my $var = $__PACKAGE__::var;
(Syntax issues aside.)

Unlike blocks and files, packages aren't lexical scopes. Switching package neither destroys the our variable (because the our variable is lexically scoped) nor change to which package variable the our variable is aliased (because package doesn't know anything about the our variable).

[ruzam]

I guess that also explains why I can put 'our $var;' in package BB and have this version of $var carried through main. Each use of 'our' replaces any previous alias for the remainder of the execution. I'll have to re-train my brain on what to expect from packages :)

Makes me a little nervous that Perl would allow this without some kind of warning. Also makes me wonder what kind of problems could be made easier using 'our' in this way?