Perl Syntax characters "::" - perl

I can't find anywhere what the :: is for in Perl. Example:
$someVariable::QUERY{'someString'};
Thanks!

These are package separators. I suspect the actual code is more like $SomePackage::SomeHash{'SomeKey'}. This syntax allows accessing a "package variable", in this case a hash, from some other package, or by its fully qualified name. You are probably more accustomed to seeing something like:
package SomePackage;
our %SomeHash;
$SomeHash{'SomeKey'} # do something with $SomePackage::SomeHash{'SomeKey'} here
A use case is setting up some module, like say Data::Dumper, which uses these package variables to control output:
use Data::Dumper;
local $Data::Dumper::Sortkeys = 1;
print Dumper { c => 3, a => 1, b => 2 };
... though this type of usage is typically avoided by using Object Oriented style.
See also: the famous "Coping with Scoping" article by MJD: http://perl.plover.com/FAQs/Namespaces.html

It's covered in Perlmod.
The :: is really a namespace identifier. In early Perl before this idea of namespace took hold, you could have variable name collisions happening in your program:
Here's my program:
#! /usr/bin/env perl
#use strict;
use warnings;
use feature qw(say);
require "test2.pl";
$foo = "bar";
futz_with_foo();
say $foo;
I set $foo to bar and never touched it. Should print out bar However, when I run my program, I get:
$ ./test.pl
WOO WOO! I MESSED WITH FOO!
In test2.pl, I have:
sub futz_with_foo {
$foo = "WOO WOO! I MESSED WITH FOO!"
}
1;
What happened is that both programs are using the same variable $foo. To get around this issue Perl gives modules the ability to have their own namespace. The original syntax was the single quote, but changed to :: in Perl 4 (if I remember correctly). You can still use the single quote. You declare your namespace with the package.
The best way to understand this is to see it in action. Try the following:
#! /usr/bin/env perl
use strict;
use warnings;
use feature qw(say);
our $foo = 'This is the value of $foo';
say '$foo: ' . $foo;
say '$main::foo: ' . $main::foo;
say "\$main'foo: " . $main'foo;;
say "\nSwitching to package Bar";
package Bar;
our $foo = 'This is in package Bar';
say '$foo: ' . $foo;
say '$Bar::foo: ' . $Bar::foo;
say "\nSwitching to package main again";
package main;
say '$foo: ' . $foo;
Running this, I get:
$foo: This is the value of $foo
$main::foo: This is the value of $foo
$main'foo: This is the value of $foo
Switching to package Bar
$foo: This is in package Bar
$Bar::foo: This is in package Bar
Switching to package main again
$foo: This is in package Bar
By default, your program starts out in the main namespace. By the way, you'll notice that I declared our $foo and not my $foo. That's because our puts the variable in the Perl symbol table where package variables are stored. The my is a lexically scoped declaration, and is now preferred. A variable declared with my only exists in its declared scope and that can't be outside of the file its in.
Maybe this will shed some light on the error message you get when you forget to declare a variable with my:
Global symbol "$foo" requires explicit package name at ...
By default, all Perl variables are Package variables (that is, they're in Perl's symbol table). The use strict pragma forces you to either declare package variables with our or forces you to use the full package name of the variable. By declaring a variable with my (like we do 99 40/100% of the time) and by using strict, we force you to declare your variables when using Perl.
Hope this helps.

The double-colon operator :: is the separator used to prefix a member of a package, module, or class with the package, module, or class that the member is form (to distinguish between similarly named methods in different containers). You can visit this page for more information.

It's not anything on its own. SomePackage::SomeHash as a whole is an identifier. $someVariable::QUERY{'someString'} refers to hash element someString of the hash %someVariable::QUERY. Hash %someVariable::QUERY is the full name of the hash %QUERY in the package someVariable.

Related

Why is *main::my_func{CODE}* a coderef when function my_func() is exported but not defined?

I have project where I renamed a Perl module because it had a too generic name and wrote a small compatibility module. I even wrote a test for the compatibility module but it was false positive. Why does this feel so hard to test? How to actually test the existence of the exported function if I can't call it because of side effects?
In my compatibility module I inherited from the new module but didn't import its functions. That wasn't enough, to my surprise. Here I built a minimal example with only 1 package involved:
use strict;
use warnings;
use feature qw(say);
{
package MyPackage;
use parent 'Exporter';
our #EXPORT = qw(foo);
}
MyPackage->import();
say *main::foo{CODE};
say *MyPackage::foo{CODE};
say main->can('foo');
say MyPackage->can('foo');
foo();
(I replaced use MyPackage with MyPackage->import() to make this example work in 1 file.)
The output:
CODE(0x55fa5cf9e750)
CODE(0x55fa5cf9e750)
CODE(0x55fa5cf9e750)
CODE(0x55fa5cf9e750)
Undefined subroutine &MyPackage::foo called at inherit.pl line 16.
This all looks like the function exists but it fails when I try to call it.
This is Perl 5.34.
Update to answer zdim’s qestion: What is the actual issue?
I moved the actual code from OldModule.pm to NewModule.pm (not their real names, of course) and created a new OldModule.pm for compatibility with existing software using that. The actual code provided both package functions via import() as well as class and object methods. So I used use parent 'NewModule' to inherit all of them. I believed this would also inherit package functions. My Test with Test2’s can_ok incorrectly showed that it worked.
Thanks to a bug report from a coworker I learned that this was not enough and found I needed to import the package functions as well.
I can’t simply call the functions in question to test the compatibility package because this is part of a CGI app and the functions actually do database operation or print out stuff to STDOUT and would pollute my TAP output. (Yes, part of my mission is to get rid of CGI, of course.)
package OldPackage;
# ABSTRACT: transitional package for new name NewPackage
use strict;
use warnings;
use NewPackage; # this is the line I added to fix the issue
use Exporter qw(import);
our #EXPORT = #NewPackage::EXPORT; # this line only declared undefined functions
1;
Exporter, in effect, does something similar to this:
*main::foo = \&MyPackage::foo;
Just like with scalars, arrays and hashes, referencing a sub vivifies the symbol. Specifically, it creates an undefined sub as if you had done sub foo;.
$ perl -M5.010 -e'
\&foo; say *foo{CODE};
sub bar; say *bar{CODE};
'
CODE(0x55da28044470)
CODE(0x55da28073750)
exists(&f) checks if it exists, and defined(&f) checks if it's defined.
$ perl -M5.010 -e'
sub foo { }
sub bar;
for (qw( foo bar baz )) {
say exists( &$_ ) ? "$_ exists" : "$_ doesn\x27t exist";
say defined( &$_ ) ? "$_ is defined" : "$_ isn\x27t defined";
}
'
foo exists
foo is defined
bar exists
bar isn't defined
baz doesn't exist
baz isn't defined

What magic in "our" or "use vars" satisfies "use strict qw(vars)"?

I have working code, but I am trying to understand why it works. I am also trying to learn more about the internals of Perl 5 (perlbrew, perl-5.26.1, Cygwin x64).
I know from perlvar and strict that use strict 'vars' works by setting flags in $^H. Perl then tests accesses to non-:: variables based on those flags. Somehow, both our and use vars mark variables so that they will pass the test. How do they do so?
For example:
perl -E 'package Foo;
use strict "vars";
use vars qw($foo);
say $foo;'
runs fine (although it produces no output). Based on the source for use vars, I tried this, which I thought would have the same effect:
perl -E 'package Foo;
use strict "vars";
my $sym = "Foo::foo"; # <-- These two lines pulled straight
*$sym = \$$sym; # <-- from the source for the vars pragma
say $foo;'
However, it gave me an error: Global symbol "$foo" requires explicit package name. I also tried $sym = "::Foo:foo" in the above, with the same result.
I checked, and $Foo::foo is in the symbol table:
$ perl -E 'package Foo;
use Data::Dumper;
use strict "vars";
my $sym = "Foo::foo";
*$sym = \$$sym;
say Dumper(\%{"Foo::"});' # <-- Foo's symbol table
Output:
$VAR1 = {
'BEGIN' => *Foo::BEGIN,
'Dumper' => *Foo::Dumper,
'foo' => *Foo::foo # <-- yep, it's there
};
What else is use vars doing that I'm missing? Does our do the same, or something different?
Update
Here's an A/B based on melpomene's answer:
Fails Succeeds
------------------------- ----------------------------------
package Foo; package Foo;
use strict "vars"; use strict "vars";
BEGIN {
package Bar;
my $sym="Foo::foo"; my $sym = "Foo::foo";
*$sym = \$$sym; *$sym = \$$sym;
}
say $foo; say $foo;
use strict 'vars' works by setting flags in $^H.
Yes, but that's an implementation detail. $^H exposes some internal interpreter state bits, but you're not supposed to touch it in normal code.
Somehow, both our and use vars mark variables so that they will pass the test. How do they do so?
This is also considered an implementation detail.
However, we can peek a bit under the hood. strict "vars" complains about undeclared variables (at compile time).
There is a hardcoded list of variables that are exempt from this check; it includes all punctuation variables (e.g. $/, $_, etc. along with $a and $b (used by sort)).
All lexically (i.e. locally) declared variables also pass strict; this is how my, our, and state work. (For our purposes local is not a declaration and does not create local variables; local temporarily changes the value of an existing variable.)
The third exception is variables exported from modules. Using global variables as part of your module interface is generally considered to be a bad idea, but some older modules still do it. English also exports variables because that's its whole point, so we'll use it as an example:
use strict;
use English qw($INPUT_RECORD_SEPARATOR);
$INPUT_RECORD_SEPARATOR = ""; # <--
my $paragraph = readline STDIN;
The line marked <-- does not throw an error because Perl remembers which variables were imported from a module.
What does "exporting" actually mean? It just means aliasing a symbol across package boundaries:
*main::foo = \$Some::Module::foo; # now $main::foo is an alias for $Some::Module::foo
The curious thing is that as far as the Perl internals are concerned, a variable is "imported" if it has been aliased in some other package. It does not matter what it was aliased to; all that matters is where the aliasing happened. use vars (ab-)uses this detail to bypass strict "vars" by exporting your own variables back at you:
package Some::Package;
use vars qw($foo);
works like
package Some::Package;
BEGIN {
package vars;
*Some::Package::foo = \$Some::Package::foo;
}
# now $foo is an alias to ... itself
The other piece of the puzzle is that use happens at compile time, like BEGIN blocks. Your example fails because your aliasing attempt only happens at runtime, which is too late for strict, and because it doesn't switch to a different package to do the aliasing.
In the end vars is just a module, written in plain Perl. our is different: It is a real keyword and part of the language. It also has different behavior: It effectively creates an alias (to a package variable), but that alias lives in a local scope, not the symbol table.
Consider e.g. the following:
my $foo = 2;
{
our $foo = "hello";
print "foo = $foo; main::foo = $main::foo\n";
}
print "foo = $foo; main::foo = $main::foo\n";
This outputs
foo = hello; main::foo = hello
foo = 2; main::foo = hello
because the inner our $foo declaration shadows the outer $foo in the inner block. Within the block both $foo and $main::foo refer to the same variable; outside $foo refers to the lexical my $foo, which is untouched.
Another difference to use vars:
use strict;
package Foo;
our $x = "hello";
package Bar;
print "$x\n"; # hello
This code works fine because package declarations don't create a new scope. There is only one unit of scoping here (the whole file), and so our $x makes $x refer to $Foo::x for the rest of the file, no matter which package you switch into.
On the other hand:
use strict;
package Foo;
use vars qw($x);
$x = "hello";
package Bar;
print "$x\n";
This code doesn't even compile. The reference to $x in the last line can't be resolved: Perl checks the local scope first, but there are no locally declared $x's. It then checks the current package (Bar) and finds nothing either, and without strict "vars" it would have automatically created $Bar::x for you, but with strict "vars" enabled this is simply an error. $Foo::x is irrelevant and never checked.

Package Variable in Perl not in "scope"?

I was looking at this question, and while I was playing around, I came across this:
#! /usr/bin/env perl
#
# use warnings;
use strict;
use feature qw(say);
{
our $foo = "bar";
say "Foo = $foo";
}
say "Foo = $foo"; # This is line #12
Yes, I do have use warnings; turned off...
When I run this, I get:
Variable "$foo" is not imported at ./test.pl line 12.
Global symbol "$foo" requires explicit package name at ./test.pl line 12.
Execution of ./test.pl aborted due to compilation errors.
Hmmm... I get the same "Variable "$foo" is not imported at ./test.pl line 12." error if I had done my $foo = "bar";. I would understand this when I use my because there is no variable $foo once we leave the block. But, our variables are suppose to be package scope. I could understand how $foo might not have a value at that point, but this?
Also, what does the "Variable "$foo" is not imported at ./test.pl line 12." mean? I understand packages and importing, but there's only a single package here, main. $foo should be in the main package. It doesn't need to be imported.
What is going on with my package variable that doesn't seem to be in the package after it falls out of scope?
Addendum
So if you used $::foo, or created another alias with our $foo; again, your program would work as expected. cmj
Let's try this...
#! /usr/bin/env perl
#
# use warnings;
use strict;
use feature qw(say);
{
our $foo = "bar";
say "Foo = $foo";
}
our $foo; # Redeclared
say "Foo = $foo"; # This is line #12
Now, this prints out:
bar
bar
As everyone who answered pointed out, our merely makes an alias to the package variable of the same name, and it's lexically scoped. That means once the alias goes out of scope, so did my ability to access the value of $main::foo with $foo. That's something I never realized before.
However, as cjm pointed out, redeclaring our $foo; restores the alias, and the already existing $main::foo is aliased back to a new $foo. When I redeclare our $foo;, the value of $foo is restored.
It's one of the things about our variables that can be so confusing. You see a declaration our $foo;, and suddenly not only does that variable exist, but it has a mysterious value. You have to search the program to see where that value could have come from.
Our declares a lexical alias to a package variable. This means that it's scoped just like my. The difference is that it's backed by a package variable, so the variable doesn't go away when you exit the scope. Only the alias goes away.
So if you used $::foo, or created another alias with our $foo again, your program would work as expected.
Our does not indicate package scope.
An our declaration declares an alias for a package variable that will
be visible across its entire lexical scope, even across package
boundaries.
This means that when the lexical scope of the block that declared it ends, it falls out of scope.
what does the "Variable "$foo" is not imported at ./test.pl line 12." mean?
perldiag says:
With "use strict" in effect, you referred to a global variable
that you apparently thought was imported from another module, because
something else of the same name (usually a subroutine) is exported by
that module. It usually means you put the wrong funny character on the
front of your variable.
That makes no sense since you didn't import anything. It shouldn't be emitted by your code. Perl's trying to be helpful in diagnosing the strict error, but got it wrong. Ignore the warning.
But, our variables are suppose to be package scope
That's not true. our creates a lexical variable just like my. That variable is aliased to the package variable with the same name.
package Foo;
our $x; # Equivalent to: alias my $x = $Foo::x;
$Foo::x = 123;
package Bar;
$Bar::x = 456;
print("$x\n"); # 123
(alias is provided by Data::Alias.)

Perl: how to make variables from requiring script available in required script

example
out.pl:
(my|our|local|global|whatever???) var = "test";
require("inside.pm");
inside.pm:
print $var;
I don't want to use packages - it's overwhelming my needs :)
thanks!
You are always using a package, even if you don't use the package declaration. By default, you're working in package main.
All variables you declare with our are package variables and should be available package wide. Here's an example:
#! /usr/bin/env perl
# test2.pl
use strict;
use warnings;
our $foo = "bar";
1;
Since $foo is declared as a package variable, it will be available in other programs:
#! /usr/bin/env perl
use strict;
use warnings;
require "test2.pl";
our $foo;
print "The value of \$foo is $foo\n";
Now I've given you enough rope, I'm going to tell you not to hang yourself with it.
This is a REALLY, REALLY BAD IDEA. Notice that $foo gets a value from some sort of mysterious mechanism that's almost impossible to figure out?
Packages are too complex? Really? It's not that hard! Look at this example:
#! /usr/bin/env perl
# test2.pm
package test2;
use strict;
use warnings;
our $foo = "bar";
1;
Not much different than before except I added the package declaration and now call my program test2.pm instead of test2.pl.
Here's how I access it:
#! /usr/bin/env perl
use strict;
use warnings;
use test2;
print "The value of \$foo from package test2 is $test2::foo\n";
All I had to do was use the package name in the variable. This is a BAD IDEA, but it's way better than the REALLY, REALLY BAD IDEA shown above.
At least, you know where the value came from. It came from test2.pm. And, you could access the variable if you set it in a subroutine.
#! /usr/bin/env perl
# test2.pm
package test2;
use strict;
use warnings;
sub fooloader {
our $foo = "bar";
}
1;
Notice that $foo is set in the subroutine fooloader. And, here's my other program to access it:
#! /usr/bin/env perl
use strict;
use warnings;
use test2;
&test2::fooloader();
print "The value of \$foo from package test2 is $test2::foo\n";
Now, you could use the Exporter to export your subroutines (and even variables), but that's not something you see too much anymore. Mainly because it is a REALLY BAD IDEA. Not as bad as the original REALLY REALLY BAD IDEA, but worse than the BAD IDEA above:
#! /usr/bin/env perl
# test2.pm
package test2;
use base qw(Exporter);
our #EXPORT = qw(fooloader);
use strict;
use warnings;
sub fooloader {
our $foo = "bar";
}
1;
Now, I can use subroutine fooloader without the package name:
#! /usr/bin/env perl
use strict;
use warnings;
use test2;
fooloader();
print "The value of \$foo from package test2 is $test2::foo\n";
The problem, of course, is that you have no real idea where the subroutine fooloader is coming from. If you used #EXPORT_OK instead of #EXPORT, you could have then use use test2 qw(fooloader); and document where the fooloader function was coming from. It'll also help you to know not to create your own fooloader function in your own program and override the one you imported. Then, wonder why your program no longer works.
By the way, you could also export variables and not just functions. However, that becomes a REALLY, REALLY, REALLY BAD -- NO TERRIBLE IDEA because it violates every reason why you use packages in the first place. If you're going to do that, why bother with packages? Why not simple take a gun and shoot yourself in the foot?
The best and preferred way is to use object oriented Perl and do it in the THOROUGHLY CORRECT WAY. A way where you know exactly what's going on and why. And, makes it easy to figure out what your code is doing. A way that keeps errors at a minimum.
Behold the thoroughly object oriented Test2 class:
#! /usr/bin/env perl
# Test2.pm
package Test2;
sub new {
my $class = shift;
my $self = {};
bless $self, $class;
return $self;
}
sub FooValue {
return "bar";
}
1;
And using that Test2 class:
#! /usr/bin/env perl
use strict;
use warnings;
use Test2;
my $tester = Test2->new;
print "The value of foo from package test2 is " . $tester->FooValue . "\n";
The reason this is the best way to do it is because even if you use packages, you could manipulate the value of $test2::foo and it will be changed in your entire program. Imagine if this was say $constants::pi and somewhere you changed it from 3.14159 to 3. From then on, using $constants::pi would give you the wrong value. If you use the object oriented method, you couldn't change the value of the method Constant->Pi. It will always be 3.14159.
So, what did we learn today?
We learned that it is very easy in Perl to do something that's a REALLY, REALLY BAD IDEA, but it doesn't take all that much work to use packages, so it merely becomes a BAD IDEA. And, if you start learning a bit of object oriented Perl, you can actually, without too much effort, do it all in the THOROUGHLY CORRECT WAY.
The choice is yours to make. Just remember the foot you're shooting will probably be your own.
It will work with our.
$ cat out.pl
our $var = "test";
require("inside.pm");
$ cat inside.pm
print "Testing...\n";
print "$var\n";
$ perl out.pl
Testing...
test
This works because our makes $var global, and inside.pm is being executed in the scope with $var defined. Not sure it is recommended technique, but it is an interesting question nevertheless!
EDIT: Need to clarify (okay patch) the answer based on a comment:
From the documentation on the Perl function our:
our associates a simple name with a package (read: global) variable in the current package, for use within the current lexical scope. In other words, our has the same scoping rules as my or state, but does not necessarily create a variable.
So using our, we get $var with the current package (here probably main) and we can use it in its scope. In effect it is then "global" to the code in the file you are requiring-in.
A true global is introduced without the our, because variables default to global. But I don't know anyone that would recommend them.

What is the difference between 'my' and 'our' in Perl?

I know what my is in Perl. It defines a variable that exists only in the scope of the block in which it is defined. What does our do?
How does our differ from my?
How does our differ from my and what does our do?
In Summary:
Available since Perl 5, my is a way to declare non-package variables, that are:
private
new
non-global
separate from any package, so that the variable cannot be accessed in the form of $package_name::variable.
On the other hand, our variables are package variables, and thus automatically:
global variables
definitely not private
not necessarily new
can be accessed outside the package (or lexical scope) with the
qualified namespace, as $package_name::variable.
Declaring a variable with our allows you to predeclare variables in order to use them under use strict without getting typo warnings or compile-time errors. Since Perl 5.6, it has replaced the obsolete use vars, which was only file-scoped, and not lexically scoped as is our.
For example, the formal, qualified name for variable $x inside package main is $main::x. Declaring our $x allows you to use the bare $x variable without penalty (i.e., without a resulting error), in the scope of the declaration, when the script uses use strict or use strict "vars". The scope might be one, or two, or more packages, or one small block.
The PerlMonks and PerlDoc links from cartman and Olafur are a great reference - below is my crack at a summary:
my variables are lexically scoped within a single block defined by {} or within the same file if not in {}s. They are not accessible from packages/subroutines defined outside of the same lexical scope / block.
our variables are scoped within a package/file and accessible from any code that use or require that package/file - name conflicts are resolved between packages by prepending the appropriate namespace.
Just to round it out, local variables are "dynamically" scoped, differing from my variables in that they are also accessible from subroutines called within the same block.
An example:
use strict;
for (1 .. 2){
# Both variables are lexically scoped to the block.
our ($o); # Belongs to 'main' package.
my ($m); # Does not belong to a package.
# The variables differ with respect to newness.
$o ++;
$m ++;
print __PACKAGE__, " >> o=$o m=$m\n"; # $m is always 1.
# The package has changed, but we still have direct,
# unqualified access to both variables, because the
# lexical scope has not changed.
package Fubb;
print __PACKAGE__, " >> o=$o m=$m\n";
}
# The our() and my() variables differ with respect to privacy.
# We can still access the variable declared with our(), provided
# that we fully qualify its name, but the variable declared
# with my() is unavailable.
print __PACKAGE__, " >> main::o=$main::o\n"; # 2
print __PACKAGE__, " >> main::m=$main::m\n"; # Undefined.
# Attempts to access the variables directly won't compile.
# print __PACKAGE__, " >> o=$o\n";
# print __PACKAGE__, " >> m=$m\n";
# Variables declared with use vars() are like those declared
# with our(): belong to a package; not private; and not new.
# However, their scoping is package-based rather than lexical.
for (1 .. 9){
use vars qw($uv);
$uv ++;
}
# Even though we are outside the lexical scope where the
# use vars() variable was declared, we have direct access
# because the package has not changed.
print __PACKAGE__, " >> uv=$uv\n";
# And we can access it from another package.
package Bubb;
print __PACKAGE__, " >> main::uv=$main::uv\n";
Coping with Scoping is a good overview of Perl scoping rules. It's old enough that our is not discussed in the body of the text. It is addressed in the Notes section at the end.
The article talks about package variables and dynamic scope and how that differs from lexical variables and lexical scope.
The perldoc has a good definition of our.
Unlike my, which both allocates storage for a variable and associates a simple name with that storage for use within the current scope, our associates a simple name with a package variable in the current package, for use within the current scope. In other words, our has the same scoping rules as my, but does not necessarily create a variable.
my is used for local variables, whereas our is used for global variables.
More reading over at Variable Scoping in Perl: the basics.
I ever met some pitfalls about lexical declarations in Perl that messed me up, which are also related to this question, so I just add my summary here:
1. Definition or declaration?
local $var = 42;
print "var: $var\n";
The output is var: 42. However we couldn't tell if local $var = 42; is a definition or declaration. But how about this:
use strict;
use warnings;
local $var = 42;
print "var: $var\n";
The second program will throw an error:
Global symbol "$var" requires explicit package name.
$var is not defined, which means local $var; is just a declaration! Before using local to declare a variable, make sure that it is defined as a global variable previously.
But why this won't fail?
use strict;
use warnings;
local $a = 42;
print "var: $a\n";
The output is: var: 42.
That's because $a, as well as $b, is a global variable pre-defined in Perl. Remember the sort function?
2. Lexical or global?
I was a C programmer before starting using Perl, so the concept of lexical and global variables seems straightforward to me: it just corresponds to auto and external variables in C. But there're small differences:
In C, an external variable is a variable defined outside any function block. On the other hand, an automatic variable is a variable defined inside a function block. Like this:
int global;
int main(void) {
int local;
}
While in Perl, things are subtle:
sub main {
$var = 42;
}
&main;
print "var: $var\n";
The output is var: 42. $var is a global variable even if it's defined in a function block! Actually in Perl, any variable is declared as global by default.
The lesson is to always add use strict; use warnings; at the beginning of a Perl program, which will force the programmer to declare the lexical variable explicitly, so that we don't get messed up by some mistakes taken for granted.
This is only somewhat related to the question, but I've just discovered a (to me) obscure bit of perl syntax that you can use with "our" (package) variables that you can't use with "my" (local) variables.
#!/usr/bin/perl
our $foo = "BAR";
print $foo . "\n";
${"foo"} = "BAZ";
print $foo . "\n";
Output:
BAR
BAZ
This won't work if you change 'our' to 'my'.
print "package is: " . __PACKAGE__ . "\n";
our $test = 1;
print "trying to print global var from main package: $test\n";
package Changed;
{
my $test = 10;
my $test1 = 11;
print "trying to print local vars from a closed block: $test, $test1\n";
}
&Check_global;
sub Check_global {
print "trying to print global var from a function: $test\n";
}
print "package is: " . __PACKAGE__ . "\n";
print "trying to print global var outside the func and from \"Changed\" package: $test\n";
print "trying to print local var outside the block $test1\n";
Will Output this:
package is: main
trying to print global var from main package: 1
trying to print local vars from a closed block: 10, 11
trying to print global var from a function: 1
package is: Changed
trying to print global var outside the func and from "Changed" package: 1
trying to print local var outside the block
In case using "use strict" will get this failure while attempting to run the script:
Global symbol "$test1" requires explicit package name at ./check_global.pl line 24.
Execution of ./check_global.pl aborted due to compilation errors.
Just try to use the following program :
#!/usr/local/bin/perl
use feature ':5.10';
#use warnings;
package a;
{
my $b = 100;
our $a = 10;
print "$a \n";
print "$b \n";
}
package b;
#my $b = 200;
#our $a = 20 ;
print "in package b value of my b $a::b \n";
print "in package b value of our a $a::a \n";
Let us think what an interpreter actually is: it's a piece of code that stores values in memory and lets the instructions in a program that it interprets access those values by their names, which are specified inside these instructions. So, the big job of an interpreter is to shape the rules of how we should use the names in those instructions to access the values that the interpreter stores.
On encountering "my", the interpreter creates a lexical variable: a named value that the interpreter can access only while it executes a block, and only from within that syntactic block. On encountering "our", the interpreter makes a lexical alias of a package variable: it binds a name, which the interpreter is supposed from then on to process as a lexical variable's name, until the block is finished, to the value of the package variable with the same name.
The effect is that you can then pretend that you're using a lexical variable and bypass the rules of 'use strict' on full qualification of package variables. Since the interpreter automatically creates package variables when they are first used, the side effect of using "our" may also be that the interpreter creates a package variable as well. In this case, two things are created: a package variable, which the interpreter can access from everywhere, provided it's properly designated as requested by 'use strict' (prepended with the name of its package and two colons), and its lexical alias.
Sources:
http://perldoc.perl.org/functions/our.html
http://perldoc.perl.org/perlsub.html#Private-Variables-via-my()
#!/usr/bin/perl -l
use strict;
# if string below commented out, prints 'lol' , if the string enabled, prints 'eeeeeeeee'
#my $lol = 'eeeeeeeeeee' ;
# no errors or warnings at any case, despite of 'strict'
our $lol = eval {$lol} || 'lol' ;
print $lol;