I have a question about packages, modules and syntax. When you access a package in the same file I notice you'd use something like....
package test;
$testVar="This is a test";
#and to access it using..
package main;
print($test::testVar);
or simply...
package test;
print($testVar);
Yet when I use this syntax for use with a module, sending an argument, I am supposed to ommit the $ from the start of the print function, yet above I don't. I noticed it didn't work otherwise and I don't know why. My materials don't clarify.
require module;
print(package::sub("argument"));
Why is that?. I'm confused.
The dollar sign here is a sigil that indicates that the named variable is a scalar.
If there is no preceding package declaration, the use of $var_name contains an implied namespace of main, i.e. it is short for $main::var_name. In the case of your example, where you have package main; first, you need to stipulate that the namespace is test, rather than main, so $test::testVar is required.
For a function call, you do not need to use a sigil. If you did, you would use the ampersand (&), but using ampersands when calling functions has fallen out of favour with many programmers.*
As before, sub_name() is a shortened version of main::sub_name()... in the same way, no sigil is needed to call package::sub().
*References as to the use of &:
Perl Monks discussion
Perl::Critic dislikes it, following on from Perl Best Practices
Per perldoc, using & with a function name allows you to deviate from the usual behaviour. This can result in subtle bugs.
Related
I've inherited some Perl code and occasionally I see subroutines defined like this:
sub do_it($) {
...
}
I can't find the docs that explain this. What does the dollar symbol in brackets mean?
It is a subroutine prototype.
The single $ means that the sub will only accept a single scalar value, and will interpret other types using scalar context. For instance, if you pass an array as the param e.g. do_it(#array), Perl will not expand #array into a list, but instead pass in the length of the array to the subroutine body.
This is sometimes useful as Perl can give an error message when the subroutine is called incorrectly. Also, Perl's interpreter can use the prototypes to disambiguate method calls. I have seen the & symbol (for code block prototype) used quite neatly to write native-looking routines that call to anonymous code.
However, it only works in some situations - e.g. it doesn't work very well in OO Perl. Hence its use is a bit patchy. Perl Best Practices recommends against using them.
The ($) is called a subroutine prototype.
See the PerlSub man page for more information: http://perldoc.perl.org/perlsub.html#Prototypes
Prototyping isn't very common nowadays. Best Practice is not using it.
$color_of{apple} = "red";
print $color_of{apple};
The above code is printing red when I have not even initialized the hash. Is this allowed in perl and will it always compile?
I can't remember the exact code but once I got the following error when the map wasn't initialized explicitly.
Global symbol "%map" requires explicit package name at ....
Code link : http://ideone.com/NJDTUj
You get that error when you use strict, which you should always do. You should also always use warnings to turn warnings on.
It is considered good practice and called Modern Perl (which is everything more or less after Perl 5.08, don't quote me on that) to always have strict and warnings. They make sure you don't have stupid mistakes, enforce that you declare variables, tell you about declaring them twice and so on.
So the answer is, you do not need to declare* any kind of variable in Perl, but you should do it anyway. Frankly, if you work with other people, those will hate you if you don't.
#!/usr/bin/env perl
use strict;
use warnings;
use feature 'say';
my %color_of; # no need to put () unless you explicitly want an empty list
$color_of{apple} = 'red';
say $color_of{apple};
*) Declaring a variable means you tell Perl that there is a variable. You do that with my, which makes a lexical variable that only lives inside a block (like a sub, or inside of the curly braces of if (1) { ... }. Initializing a variable means to give it a value before you use it. Usually that is done at the same time as declaring it in Perl. If you do not do that, the variable will be undef, which is perfectly fine.
An even stricter approach is to use strictures, which you need to install from CPAN.
Consider the following script p.pl:
use strict;
use warnings;
use AA;
BB::bfunc();
where the file AA.pm is:
package AA;
use BB;
1;
and the file BB.pm is:
package BB;
sub bfunc {
print "Running bfunc..\n";
}
1;
Running p.pl gives output (with no warnings or errors):
Running bfunc..
Q: Why is it possible to call BB::bfunc() from p.pl even though there is no use BB; in p.pl? Isn't this odd behavior? Or are there situation where this could be useful?
(To me, it seems like this behavior only presents an information leak to another package and violates the data hiding principle.. Leading to programs that are difficult to maintain.. )
You're not polluting a namespace, because the function within BB isn't being 'imported' into your existing namespace.
They are separate, and may be referenced autonomously.
If you're making a module, then usually you'll define via Exporter two lists:
#EXPORT and #EXPORT_OK.
The former is the list of things that should be imported when you use the package. The latter is the things that you can explicity import via:
use MyPackage qw ( some_func );
You can also define package variables in your local namespace via our and reference them via $main.
our $fish = "haddock";
print $main::fish;
When you do this, you're explicitly referencing the main namespace. When you use a module, then you cause perl to go and look for it, and include it in your %INC. I then 'knows about' that namespace - because it must in order for the dependencies to resolve.
But this isn't namespace pollution, because it doesn't include anything in your namespace until your ask.
This might make a bit more sense if you have multiple packages within the same program:
use strict;
use warnings;
package CC;
our $package_var = "Blong";
sub do_something {
print $package_var,"\n";
}
package main;
use Data::Dumper;
our $package_var = "flonk";
print Dumper $package_var;
print Dumper $CC::package_var;
Each package is it's own namespace, but you can 'poke' things in another. perl will also let you do this with object - poking at the innards of instantiated objects or indeed "patch" them.
That's quite powerful, but I'd generally suggest Really Bad Style.
While it's good practice to use or require every dependency that you are planning to access (tried to avoid use here), you don't have to do that.
As long as you use full package names, that is fine. The important part is that Perl knows about the namespaces. If it does not, it will fail.
When you use something, that is equivalent to:
BEGIN {
require Foo::Bar;
Foo::Bar->import();
}
The require will take the Foo::Bar and convert it to a path according to the operating system's conventions. On Linux, it will try to find Foo/Bar.pm somewhere inside #INC. It will then load that file and make a note in %INC that it loaded the file.
Now Perl knows about that namespace. In case of the use it might import something into your own namespace. But it will always be available from everywhere after that as long as you use the full name. Just the same, stuff that you have in your main script.pl would be available inside of packages by saying main::frobnicate(). (Please don't do that!)
It's also not uncommon to bundle several namespaces/packages in one .pm module file. There are quite a few big names on CPAN that do it, like XML::Twig.
If you do that, and don't import anything, the only way to get to the stuff under the different namespaces is by using the full name.
As you can see, this is not polluting at all.
Short version
Is it possible to access variables from a module declared as our using unqualified names within the BEGIN code block, but using qualified names outside? In particular, can this be done without explicitely naming the package in the module file?
Example
Let demomod.pm be
use strict;
use warnings;
package demomod;
our $foo;
BEGIN { $foo = 42; }
1;
and demoscript.pl be
#!/usr/bin/perl -Tw
use strict;
use warnings;
BEGIN { #INC = ('.', #INC); }
use demomod;
print $demomod::foo."\n";
In this case, all names agree, and everything works as it should. Is there a way to omit the line package demomod; from the demomod.pm code and still let this work?
Motivation
The reason why I'm asking is because I encountered something along these lines during a recent upgrade of Foswiki. That software has a module Foswiki.pm which does not have a package line (EDIT: seems the package line only got lost in my local copy, for reasons unknown). It declares and initializes a variable $engine like in my example. There also is a CGI script called view which sets #INC and then does use Foswiki (); followed by $Foswiki::engine->run(). This last line always fails for me due to the variable not being initialized:
Can't call method "run" on an undefined value at …/view
In the BEGIN block of the module, $engine is set correctly but $Foswiki::engine apparently is not. So it looks like there were two variables here, one qualified and a different one unqualified.
All that code apparently works for others, and a previous version used to work for me as well, without a package line either. So while I try to understand how this broke, I also try to understand how this could work before, without that line in place. Is there some mechanism that would make this work?
If you have no package statement in your code then any package variables will be declared into the main package. So no, you cannot do what you describe.
If you look at line 2 of the Foswiki code that you linked, you will see that it does have a package statement.
I'm looking at some older Perl code on Perl Monks to figure out programming with Win32::OLE and MS Word. Scattered throughout the code are variables with names like $MS::Word and the like, without a 'my' included in their declaration. After reading a bit on Google, I understand that these are called 'package variables' versus 'lexical variables' declared using my.
My first question is 'What are package variables good for?'. I (think) I understand what lexical variables are, but I don't understand the purpose of package variables or how their use differs from lexicals, so my second question would be, 'What is the difference between lexical and package variables?'
You should read Coping with Scoping by MJD.
perldoc perlmod would also be useful reading.
The code is out of this world ugly. It tramples on all sorts of namespaces without a concern in the world just because the author seems to think $author::email is cool.
A better way would have been to use a hash:
my %author = (
email => 'author#example.com',
...
);
Trampling all over the symbol table is not necessary.
I do have a few Win32::OLE examples: http://www.unur.com/comp/ which are no works of art but I believe are improvements on this style. See also Why are the number of pages in a Word document different in Perl and Word VBA?
I am going to rant a little:
#pgm::runtime_args = #ARGV ;
So, we give up on the standard #ARGV array to trample on the pgm namespace. Not only that, every Perl programmer knows what #ARGV is. In any case, #pgm::runtime_args is not used again in the script.
$pgm::maxargs = $#pgm::runtime_args + 1 ;
Of course #pgm::runtime_args in scalar context would give us the number of elements in that array. I have no idea why $pgm::maxargs might be needed, but if it were, then this line should have been:
$pgm::maxargs = #pgm::runtime_args;
I am not going quote more of this stuff. I guess this is what happens when Cobol programmers try to write Perl.
$program::copyright = "Copyright (c) 02002 - Kenneth Tomiak : All rights reserved.";
I am glad he allocated five digits for the year. Ya never know!
PS: I believe my excerpts constitute fair use.
A package variable lives in a symbol table, so given its name, it's possible to read or modify it from any other package or scope. A lexical variable's scope is determined by the program text. The section "Private Variables via my()" in the perlsub manpage gives more detail about defining lexicals.
Say we have the following MyModule.pm:
package MyModule;
# these are package variables
our $Name;
$MyModule::calls = "I do not think it means what you think it means.";
# this is a lexical variable
my $calls = 0;
sub say_hello {
++$calls;
print "Hello, $Name!\n";
}
sub num_greetings {
$calls;
}
1;
Notice that it contains a package $calls and a lexical $calls. Anyone can get to the former, but the module controls access to the latter:
#! /usr/bin/perl
use warnings;
use strict;
use MyModule;
foreach my $name (qw/ Larry Curly Moe Shemp /) {
$MyModule::Name = $name;
MyModule::say_hello;
}
print MyModule::num_greetings, "\n";
print "calls = $MyModule::calls\n";
The program's output is
Hello, Larry!
Hello, Curly!
Hello, Moe!
Hello, Shemp!
4
calls = I do not think it means what you think it means.
As you can see, package variables are globals, so all the usual gotchas and advice against apply. Unless explicitly provided access, it's impossible for code outside the MyModule package to access its lexical $calls.
The rule of thumb is you very nearly always want to use lexicals. Perl Best Practices by Damian Conway is direct: "Never make variables part of a module's interface" (emphasis in original).
Package variables are global variables; they're visible everywhere in the entire program (even other modules). They're useful when you want or need that level of visibility and/or external influence. For example the Text::Wrap module uses them to allow a single configuration point for the number of columns at which to wrap text. Futhermore, package variables allow you to use something called "dynamic scoping" -- but that's a somewhat advanced and slightly esoteric concept.
For your second question, see What is the difference between my and our in Perl?