Pablo Fischer wrote at Sun, 27 Jul 2003 11:59:59 +0000:
> I have a Pretty class, with 15 methods (or more). I was reading a Perl
> Tutorial and read that I could create local variables. So In many of my
> methods Im using variables, but Im not declaring them like 'local $var', just
> like 'my $var'. So I changed a few variables from 'my' to 'local', and When I
> tried to see if it was working I got:
>
> [EMAIL PROTECTED] Perl]$ perl Persona.pm
> Global symbol "$name" requires explicit package name at Persona.pm line 22.
> Global symbol "$name" requires explicit package name at Persona.pm line 24.
> Global symbol "$name" requires explicit package name at Persona.pm line 25.
> Global symbol "$name" requires explicit package name at Persona.pm line 26.
> Execution of Persona.pm aborted due to compilation errors.
Usually you will only use "my" and "our" variable declarations.
"my" declares a variable that is scoped to the current lexical block.
Allthough that might sound hard at the first time, it's just the usual
variable declaration for non-global variables, like in your subroutines.
With "our" you declare global (package scobed variables).
With "local" you declare a localiced variation of a _global_ variable.
That's not that frequent used, as you first need a global variable and
then a reason why to overwrite it and finally why only at the current
lexical block :-) Especially it's usually sensless to use it for
subroutine arguments.
Some useful and standard moments to use it are e.g.
local @ARGV = <*.txt>;
while (<>) {
# ...
}
local $/ = undef;
my $whole_text_of_a_file = <FILE>;
local $ENV{CLASSPATH} = "path/to/a/some/java/excecutable/files";
`java some.boring.java.program"
In the first snippet, you change the global @ARGV holding the arguments
passed to the script, just to use the nice power of the <> operator. It
would be boring to write
foreach my $file (<*.txt>) {
open FILE, $file or die "...";
while (<FILE>) {
# ...
}
}
In the second snippet you change the global line separator to slurp whole
a file in and in the third, you change an environment variable so that you
can e.g. call an evil external program with a special setting.
All these cases (and most of the other useful cases for local in use) have
in comman, that there is a powerful use of a global variable that is so
nice that it would be foolish to use non-global or different variables. Of
course, you could simulate the behaviour of every local with
my $old_value = $global_variable;
$global_variable = $local_value;
# ...
$global_variable = $old_value;
But as it is very boring and errorprone (and perhaps more threadsafe),
the local statement is used instead.
For all the rest of information, please read the already recommended
perldoc perlsub
Greetings,
Janek
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
