Roman Daszczyszak wrote:
In my perl script, I have a "global" variable called
@excludedIPAddresses, declared at the top of the script using my:
[...]
When I run this, I get an error "Can't localize lexical variable". I
understand that it's because the variable is declared using "my"; what
I don't understand is why, or what I should declare the variable as,
since if I leave out "my" I get an error using "use strict".
The C<my> and C<our> declarators have less to do with scope than with
storage and access.
Variables declared with C<my> are limited to the scope in which they are
declared and any inner scopes, and are known as "local" or "lexical"
variables. They may be re-declared within an inner scope, in which case
the inner scope masks the outer, but the outer variable still exists, it
retains its value, and it will be accessible again when control returns
to the outer scope. For C<my> variables, storage is tied to the scope in
which the variable is declared, in a "scratchpad" that is thrown away at
the end of the scope. C<my> variables can also be global variables when
declared in a large scope.
Variables declared with C<our> are tied to a package and are stored as
part of the package, and are known as "package" variables. They are
accessible anywhere in the package by using the short name or outside
the package by using the fully qualified name (i.e.
<type-glyph><package-name>::<variable-name>).
You can simulate the scoping rules of C<my> variables with the C<local>
function(?). C<local> creates a copy of the _value_ of the outer package
variable that masks any previous value. The new _value_ exists only
within the scope in which the C<local> function was used.
C<local> does not declare a variable unless you run without the 'strict'
pragma. Without 'strict' it creates the package variable for you, but
when using 'strict', it generates an error requiring you to either
declare it with C<our> or to fully qualify it with the package name.
Mixing variables of the same name with different storage is where things
are sometimes less clear. (And some of the rules have changed slightly
through different revisions of perl.) So, generally you should avoid
using variables of the same name with different storage declarators.
When Perl sees code like:
use strict;
my $foo;
local $foo;
It first creates the "lexical" variable $foo. It then evaluates the call
to C<local> by first trying to resolve the name of the variable it
refers to. Since the only $foo it knows about is a "lexical" variable,
it warns you that you are trying to use C<local> on a "lexical" variable.
If you declare a "package" variable:
use strict;
my $foo;
our $foo;
local $foo;
Perl will resolve the name $foo referenced in the call to C<local> to
the "package" variable and will happily use it.
IOW, the error comes about during the process of trying to resolve the
variable name. If the variable name resolves to the wrong type of
variable, you get an error. You could also help Perl to resolve the name
by fully qualifying it:
use strict;
my $foo;
local $PackageName::foo;
__END__
Regards,
Randy.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
