The second "our" does create a new lexical variable, but it is aliased to the package variable. Effectively, it is the same variable.

If you wanted to localize it, you need to use "local".

In practice, it would be very rare to find code using "our" inside a block. It is typically used at the top of the file, because it declares (package) global variables.

Even if you did use "our" inside of a block, it just gives you access to the global variable for that block only.

Note: None of this really matters until you say "use strict". Without strict, you can use global variables anywhere. With strict, you must use "our" to declare the variables.

There are actually uses (well, at least one that I can think of) for our beyond use 'strict' context. I have had occasion to use our at the top of a file that contained multiple packages so that I could have a package global that was accessible without full qualification throughout the file. E.g.:

package X;

our $global = 'Xglobal';

... more stuff here ...

package Y;

print $global;
[download]

When run, this code prints Xglobal even though the reference to $global is in package Y's space and it was defined as being a global in package X. The our makes all unqualified references to the variable be assumed to be in the X package namespace even after you move into a different namespace. The same effect can be obtained with my(), except that then the variables are not accessible to other perl code that uses/requires this code.

--DrWhy

"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

our $var = 1;
{
    package Inner;       # new package declaration
    our $var = 2;
    print $var, "\n";    # prints 2
}
print $var, "\n";        # prints 1,
                         # cause we're back in the "outer" package
                         # (main, by default)
[download]

Ciao,
Emanuele.

If our() has the same scoping rules as my()

The scoping rules are only the same in terms of where the variable is accessible. Meaning you can only access a lexical variable within the current lexical scope. Outside of that, you will get an error (if you're using strict). The rules aren't the same when it comes to how long the variables live, as you've discovered.

And if the othe various posts haven't illuminated yet, it's worth walking through some other examples step by step. (Including strict and warnings.)

Using all fully qualified globals:

use strict;
use warnings;

$main::var = 1;
{
    $main::var = 2;
    print $main::var, "\n";    # prints 2
}
print $main::var, "\n";        # also prints 2
[download]

Declaring within the block:

use strict;
use warnings;

$main::var = 1;
{
    our $var = 2;
    print $var, "\n";    # prints 2
}
print $main::var, "\n";        # also prints 2
[download]

Declaring within the block and trying to use unqualified later (on line 9) causes a compile-time error under strict -- the "our" only has its effect of allowing use of the variable name without fully qualifiying it while within the block:

use strict;
use warnings;

$main::var = 1;
{
    our $var = 2;
    print $var, "\n";    # prints 2
}
print $var, "\n";        # also prints 2
[download]

Typical usage "at the top" applies to the whole file:

use strict;
use warnings;

our $var = 1;
{
    $var = 2;
    print $var, "\n";    # prints 2
}
print $var, "\n";        # also prints 2
[download]