From the "our" perldoc:
our has the same scoping rules as my, but does not necessarily create a variable.
This means that variables declared with our should not be visible across files, because file is the largest lexical scope. But this is not true. Why?
You can consider our to create a lexically-scoped alias to a package global variable. Package globals are accessible from everywhere; that's what makes them global. But the name created by our is only visible within the lexical scope of the our declaration.
package A;
use strict;
{
our $var; # $var is now a legal name for $A::var
$var = 42; # LEGAL
}
say $var; # ILLEGAL: "global symbol $var requires explicit package name"
say $A::var; # LEGAL (always)
{
our $var; # This is the same $var as before, back in scope
$var *= 2; # LEGAL
say $var; # 84
}
You have a good answer already, but perhaps this will be helpful as well.
The our declaration combines aspects of my and use vars. It functions similarly to use vars in that it declares package variables; however, variables declared in this way are lexically scoped and cannot be accessed outside the scope in which they were declared (unless you use the fully qualified name of the variable). In addition, a variable declared with our is visible across its entire lexical scope, even across package boundaries.
Here's a table that I added to my Perl notes a while back. For an example, see this SO answer.
Scope/ Package
Namespace Variable Private New
---------------------------------------------------
my Lexical No Yes Yes
our Lexical Yes No No
use vars Package Yes No No
Related
I have below Perl code.
use warnings;
use strict;
my $x = "global\n";
sub a {
print $x;
}
sub b {
local $x = "local\n";
a();
}
a();
b();
a();
Even if $x has scope inside b() subroutine why Perl doesn't allows to localize it ?
You cannot mix the lexical scope used by my with the namespaced global scope of package variables (the keyword local may only be used on the latter). Perl will treat $x in the source as the lexically-scoped variable once you have defined it as such. You can still access the package variable (using $::x) - although that would just mean you had two entirely separate variables in use, and would not allow you to refer to either at the same time as $x.
You can achieve something very similar to what you appear to be trying to do by using our instead of my:
our $x = "global\n";
The our keyword creates a lexically-scoped alias to a package variable.
Output is then:
global
local
global
I just wanted to know what is the motivation behind this constraints.
my is thought of as a creator of statically scoped variables.
local is thought of as a creator of dynamically scoped variables.
So you have two similarly-named variables in your program. Given the whole point of my was to replace local, of course my takes precedence over local and not the other way around. You would lose the benefits of my if it was the other way around.
I am having few doubts about the local/our scope in Perl. I read a lot of documentation, but I am still in confusion is there. Following are the confusions
What is local scope?
what I read is -> local copies the value of global variable, change the value, user will use it and outside the block it will retain the global value
Confusion -> my does the same thing. Only benefit I see is that some variables like $package::var cannot be declared with my scope but can be declared with local scope. What else for local
What is "global" variable?
What I read is -> Its scope is within the package. Basically we put the global variable in #EXPORT array and use it or append the namespace with it to use in other packages.
I doubt -> Again if we declare variable with my scope in main only then we can access the variable throughout the package. Is that right? Is it possible to add the my scoped variables in #EXPORT array and use it in another packages?
I think global variables are declared with our keyword. Is there any other way to do so?
This question may look repetitive, but I am confused.
In terms of scoping, there are three kinds of variables in Perl.
Lexical variables are lexically scoped, which means they are only visible in the current lexical scope (basically file or block).
Package variables, on the other hand, can be used using their qualified form (e.g. $Foo::x) from anywhere in the interpreter, and they can be used without qualification by any code that shares the variable's package.
Certain package variables are visible without qualification anywhere in the interpreter. These include punctuation vars and a few named vars such as #ARGV and STDOUT. For example, $x refers to $Foo::x when in package Foo and $Bar::x when in package Bar (assuming no lexical var named $x is in scope), but $_ always refers to $::_.
Variables are destroyed when they are no longer referenced.
Lexical variables are usually destroyed when the lexical scope is exited.
Package variables are usually destroyed when the program exits.
Here are ways to create variable.
my and state create a lexical variable.
our creates a lexical variable that is aliased to the variable of the same name in the current package. In other words, our $x; is equivalent to my \$x = \$Foo::x; when in package Foo.
Package variables are created on use.
local doesn't create any variables. It simply backs up a variable until the current lexical scope is destroyed. It is restored from its backed-up value at that point.
my does the same thing.
No. local does not change the scope of a variable. While a lexical variable is only visible in a lexical scope, a localized package variable is still visible across the entire interpreter.
$x = 123;
sub foo { print "$x\n"; }
{ local $x = 456; foo(); } # 456
foo(); # 123
$x = 123;
sub foo { print "$x\n"; }
{ my $x = 456; foo(); } # 123
foo(); # 123
What else for local
local is primarily used to approximate the functionality of my for variables that cannot otherwise be declared lexically.
Historically, that was all variables. Since 5.6, only punctuation variables cannot be declared lexically.
What is "global" variable?
A global variable is a variable that can seen globally.
All package variables can be seen by any code in the interpreter, so they're all global.
Or are they? To see them from other packages, you need to qualify them. Are $x and $Foo::x the same variable?
To some, global variables refers to the set of package variables you can use unqualified. It means that package changes the set of global variables. And since the package directive is usually used on a file-basis, that means file-level lexicals are also effectively global by this definition. And they are indeed called that sometimes.
But if the package changes the set of variables that are global, then they're not really global, are they? So think some people, which only consider punctuation variables (e.g. $_) and the few named variables that can be used unqualified from anywhere (*::STDOUT) to be global.
In short, it's a pretty useless term.
Is it possible to add the my scoped variables in #EXPORT array and use it in another packages?
No. #EXPORT is used by Exporter. Exporter would not be able to find anything but package symbols (since files are compiled in fresh lexical scopes), so #EXPORT must only contain package symbols.
There are two kinds of variables, lexically scoped and globally scoped.
In Perl before version 5, there was only globally scoped. These variables are the package variables. These variables are available everywhere in the program if you use the package prefix.
The local keyword was introduced to provide a way to alter the value of one of these package global variables inside a limited scope, such as inside one subroutine. It will save the old value on a stack when entering the scope with the local statement, and upon exiting, it will restore the old value. These are still package globals, which means that they are still available everywhere. If you are inside a scope with a local variable, and you call a subroutine, that variable is still visible inside that subroutine.
The my keyword was introduced in version 5, and provides lexically scoped variables. These variables only exist inside the scope where they are declared. This means that if you call a subroutine, that my variable is not visible. Upon exiting a scope, the my variables simply go away. You should prefer to use my variables when possible, because you do not want your variables to be visible inside subroutines that you call. You cannot use these type of variables in the #EXPORT list because these variables are not visible outside of their scope.
Finally, the our keyword is a combination of both, in that it gives you a variable that is a package global, but that variable is lexically scoped. This means it will be available anywhere in the program, but at the end of the enclosing block, you cannot refer to that variable any more.
Here's what I found out about variable scopes:
my declarations are pretty clear and straightforward if used inside blocks. If used in main outside any block, they are a bit different though, meaning that a my variable declared outside a block is visible even inside functions called from anywhere inside the same file as long as these functions are defined within the same file. If declared inside a block, though, they are not visible to functions even if called from the same block. All my variables seem to live on the stack. And: you cannot localize them with local.
our variables live on the heap. Even if you have a my variable by the same name, the our variable can still be accessed through ${'var'}, which looks up a variable of that name in the symbol table and dereferences it. my variables, on the other hand, have not symbol table entries.
local variables seem to me like a relic from former Perl versions. They are just re-assignments to global (our) variables with block scope and resume their former values after the block terminates. I can see no real sense in using them.
My little program below shows all this, and it shows how badly a declared() test is missing, beyond the well-known defined() test, to identify undeclared variables as such.
#!/usr/bin/perl
use strict;
### This is about variable scoping with my, our and local
my $fsv = "file scope"; # visible for all code in this file
our $gsv = "global scope"; # not different from my $fsv, except in packages
our $lsv = "global"; # global scope, but localized in subsequent block
{
my $bsv = "lex scope"; # visible only inside this block, not even in subs called from here
$gsv = "visible everywhere";
local $lsv = "global, but localized val";
print "This is variable \$bsv with value $bsv inside block\n";
print "This is variable \$fsv with value $fsv inside block\n";
print "This is variable \$lsv with value $lsv inside block\n\n";
print_vars("calledfromblock");
}
print_vars("calledfromoutside");
no strict 'vars'; # needed if testing variable for declaredness rather than definedness
if ( defined $bsv ) {
print "\$bsv as defined outside braces: $bsv\n"
} else {
print "\$bsv not defined outside braces\n";
}
print "This is variable \$lsv with value $lsv outside block\n";
# use strict 'vars'; # no strict 'vars' effective even in sub print_vars unless switched back on
sub print_vars
{
my $whence = shift;
my $gsv = "my variable";
no strict 'refs'; # needed to access the global var $gsv using ${'gsv'} despite the my declaration
if ( $whence eq "calledfromblock" ) {
print "\t print_vars called from within the block:\n";
( defined $bsv ) ? print "\$bsv is $bsv inside sub\n" : print "\$bsv not defined inside sub\n";
( defined $fsv ) ? print "\$fsv is $fsv inside sub\n" : print "\$fsv not defined inside sub\n";
( defined ${'gsv'} ) ? print "\$gsv is ${'gsv'} inside sub\n" : print "\$gsv not defined inside sub\n";
( defined ${'lsv'} ) ? print "\$lsv is ${'lsv'} inside sub\n" : print "\$lsv not defined inside sub\n";
} else {
print "\t print_vars called from outside the block:\n";
( defined $bsv ) ? print "\$bsv is $bsv inside sub\n" : print "\$bsv not defined inside sub\n";
( defined $fsv ) ? print "\$fsv is $fsv inside sub\n" : print "\$fsv not defined inside sub\n";
( defined $gsv ) ? print "\$gsv is $gsv inside sub\n" : print "\$gsv not defined inside sub\n";
( defined $lsv ) ? print "\$lsv is $lsv inside sub\n" : print "\$lsv not defined inside sub\n";
}
print "\n";
}
###Example 1:
sub mess_with_foo {
$foo=0;
}
sub myfunc {
my $foo=20;
mess_with_foo();
print $foo;
}
myfunc();
###Example 2:
sub mess_with_foo {
$foo=0;
}
sub myfunc {
local $foo=20;
mess_with_foo();
print $foo;
}
myfunc();
Example 1 prints 20 because mess_with_foo() could not see my $foo. It could not change it. my $foo can only be seen in its scope of myfunc().
Example 2 prints 0 because mess_with_foo() can see my $foo and change it. local $foo can be seen in its scope of myfunc() AND in the scope of any function called from within its scope of myfunc().
That's the only difference. Neither my $foo nor local $foo will be seen outside of their scope of myfunc().
Is the our modifier only used when strict pragma is active to let using global variables or is it even used for some extra features different from normal global variables when strict is off?
Yes, our declarations can have additional features when compared with undeclared globals. But these are largely irrelevant.
our creates a lexical alias to a global variable (of the same name). That is, in package Foo, our $bar and $Foo::bar refer to the same variable. However, the former is only available in a tight lexical scope.
As our has a lexical effect, the alias can also shadow lexical variables with my:
our $foo = 42; # give some value
my $foo = -1; # same name, different value
say "my gives $foo";
our $foo; # reintroduce the alias; shadow lexical
say "our gives $foo";
If you strip the our declarations and run it without strict, this obviously won't give the output
my gives -1
our gives 42
Just like my, our can take a bit extra declaration syntax, e.g. attributes:
use threads::shared;
our $foo :shared;
You can also specify a type for usage with the fields pragma:
our Foo $foo;
This can't be done for global variables without our.
As you can see from the perldocs, our creates an alias to a package variable with the same name as the oured variable in the current package.
If you're writing code that has multiple package definitions in it, you could use an oured variable to pass an aliased variable between modules.
package Foo:
our $bar = 42; # $bar is an alias for $Foo::bar
package Baz;
print $bar; # prints '42', since $bar is $Foo::bar
Thus, a usage that has nothing to do with global variables.
Global, package variables are accessible anywhere, whether strict is in place or not, if you specify the fully-qualified name, i.e. you prefix it with the package name. So I can access $main::variable anywhere at any time.
Without strict, if you access $variable that you haven't declared with my, Perl assumes it is a package variable in the current package. our can be used to explicitly declare a package variable, but without strict it doesn't do much as anything undeclared behaves the same way.
With strict in place, variables declared with our are accessible using their local name as well as their fully-qualified name, in the lexical scope where the declaration appeared. That means that to access a global variable from two subroutines you must either declare it within both subroutines or declare it before both of them at an outer scope.
Previously I read related content in the book of "Effective Perl Programming", but didn't really understand it. Today, I encountered a problem about this, as below code.
my $vname = "a";
my #a = qw(1 2 3);
local #array = #$vname;
foreach(#array) { print "$_\n"; };
It output nothing. Then I modified this line:
local #a = qw(1 2 3);
Just replaced "my" with "local", then it works now. So I'd like to figure out what's the difference between them.
There is a perldoc entry which answers this question in perlfaq7:
What's the difference between dynamic and lexical (static) scoping? Between local() and my()?
local($x) saves away the old value of the global variable $x and
assigns a new value for the duration of the subroutine which is
visible in other functions called from that subroutine. This is done
at run-time, so is called dynamic scoping. local() always affects
global variables, also called package variables or dynamic variables.
my($x) creates a new variable that is only visible in the current
subroutine. This is done at compile-time, so it is called lexical or
static scoping. my() always affects private variables, also called
lexical variables or (improperly) static(ly scoped) variables.
For instance:
sub visible {
print "var has value $var\n";
}
sub dynamic {
local $var = 'local'; # new temporary value for the still-global
visible(); # variable called $var
}
sub lexical {
my $var = 'private'; # new private variable, $var
visible(); # (invisible outside of sub scope)
}
$var = 'global';
visible(); # prints global
dynamic(); # prints local
lexical(); # prints global
Notice how at no point does the value "private" get printed. That's
because $var only has that value within the block of the lexical()
function, and it is hidden from the called subroutine.
In summary, local() doesn't make what you think of as private, local
variables. It gives a global variable a temporary value. my() is what
you're looking for if you want private variables.
See Private Variables via
my() in perlsub
and Temporary Values via
local() in perlsub
for excruciating details.
my creates a new variable. It can only be seen in the lexical scope in which it is declared.
local creates a temporary backup of a global variable that's restored on scope exit, but does not reduce its scope (it can still be seen globally). It does not create a new variable.
You always want to use my when possible, but local is a decent approximation when you have to deal with global variables (e.g. $_).
There are two kinds of variable scopes in Perl:
Global variables: They reside in the current package, can be accessed from the outside and can have "local" values. The name can be used as a key in the "stash", the package variable hash / the symbol table.
Lexical variables: They reside in the current scope (roughly delimited by curly braces). There is no symbol table that can be inspected.
Lexical variables and global variables do not interfere, there can be two different variables with the same name.
Most Perl variable magic happens with global variables. The following syntax works with global variables:
our $var;
$::var;
$main::var;
${'var'};
local $var;
but not my $var.
So we can write:
#::array = qw(a b c);
my #secondArray = #{array};
Which copies the arrays. We can also look up the array with a name that is stored in a variable:
#::array = qw(a b c);
my $name = "array";
my #secondArray = #{$name};
The last line abbreviates to … = #$name.
This is not possible with lexical vars because they do not reside in the stash.
The local function assigns a "local" value to a global variable (and globals only) within the current scope and in the scope of all subs that are called from within this scope ("dynamic scope").
Originally (in Perl 4) meddling with variable names and the stash was the only way to simulate references. These usages are now mostly outdated by ~2 decades as references are available (what is far safer).
I would like to focus on the main cases when you would use them :
my should be your "default" for variables that you wish to keep restricted to a specific block. This should be most of the time
local is useful if you wish to use a global variable, particular one of the special variables. For example
local $/; # enable "slurp" mode
local $_ = <$some_file_handle>; # whole file now here
Using local prevents your change from affecting other code (including modules you didnt write)
In your case, the difference is that local addressed a variable in the symbol table and my does not. This is important because of how to use it:
local #array = #$vname;
That is, you're using $vname as a symbolic reference (a questionable practice absent no strict 'refs' to tell us you know what you're doing). Quotha:
Only package variables (globals, even if localized) are visible to
symbolic references. Lexical variables (declared with my()) aren't in
a symbol table, and thus are invisible to this mechanism.
So symbolic references can only refer to variables in the symbol table. Whether you declare #a as lexical with my or as global with local, #$vname only ever refers to #main::a. When you say
local #a = qw(1 2 3);
, you are giving a new value to #main::a. When you say
my #a = qw(1 2 3);
, you are creating a new lexical variable #a and giving it a value, but leaving #main::a undefined. When
local #array = #$vname;
then accesses the value of #main::a, if finds it to be undefined and sets the value of #array to it.
If all that seems confusing, that's because it is. This is why you are strongly encouraged to use strict and warnings (which would have exploded prettily on this code) and discouraged from using symbolic references unless you really know what you're doing.
Before writing this program,I thought that our is a package scope variable and my is
a file scope variable.But,After did that program,I am get confused.
My program is,
#!/usr/bin/perl
use strict;
use warnings;
package one;
our $val = "sat";
my $new = "hello";
print "ONE:val =>$val \n";
print "ONE:new =>$new \n\n";
package two;
print "TWO:val =>$val \n";
print "TWO:new =>$new \n";
which outputs
ONE:val =>sat
ONE:new =>hello
TWO:val =>sat
TWO:new =>hello
So,what is the difference between my and our.Whether the both are the same or it having any difference?
As you see, both my and our have lexical effect.
my creates a lexically scoped variable.
our creates a lexically scoped alias to a package variable.
Just because you say package in no fashion changes the lexical scope, so your $val is still an alias to $one::val even after having seen the package two statement.
If you don’t see a close curly, you haven’t finished your scope. (Or EOF or end of string in a string eval).
my restrict the variables access to the innermost block in which
they were declared. If there is no block, they are file-scoped.
our instead associates a
simple name with a package variable in the current package , so it is declared at the package level and linked to the package name. our tries to help out by letting you use package variables without adding the package name.
package pack;
our $variable; # These are the same
$pack::variable; # These are the same
An our variable is something similar to C's static variable, but is different because the variable declared with our in a function is still accessible outside the function if it is called with the variable's fully qualified name.
But most of all my is lexically scoped while our is lexical scope but their life persistent even outside the declaring block(their life is like global variable life), therefore to really understand the difference between my and our you have to understand the difference between lexically and global scoped in Perl.
So briefly the difference between the two type are :
Global variables
Any code, anywhere, can change their values.
Lexical variables
The life of the variable end with the the end of the code block in with they are included, after that their values are garbage collected. These kind of variables can be accessed only within the block in which they are declared.
To answer you specific example-question : try to move the second package declaration (package two) into another file, and you will see the difference between my and our ...
It is important to distinguish between visibility and lifetime.
The visibility of variables declared using our or my is identical. You can used the name anywhere after the declaration before the first enclosing brace or end of file.
Beware that this doesn't apply to full-qualified variable names, which need no declaration and can be accessed anywhere. Without declaring anything I can assign to a package variable
$pack::three = 3;
and use that anywhere else in any package. I don't even have to declare the pack package. But if I write
package pack;
our $three;
I have generated an shortened alias for $pack::three that I can use within the same lexical scope as I could a my variable in the same place: before an enclosing brace or end of file.
These package variables are always available from the start of the program's execution. Just like hash elements you can always assign to a new one and it will always be there - their lifetime is endless. In fact package variables are hash elements to all intents and purposes.
Lexical variables, declared with my, on the other hand, are created at the point of declaration and destroyed once they go out of scope and there is no reference to them held anywhere. So, unless you take the reference of such a variable, its lifetime is the same as its visibility. A my declaration inside a loop causes a new variable to be created and destroyed for each execution the loop.
In your code, you have created an alias $val for package variable $one::val and a lexical variable $new. Neither are within a code block so both are visible to the end of the file. The package two has no effect at all here, but if you had written our $val after that second package statement you would have changed the alias $val to indicate $two::val instead.
I hope that helps.