(The old package delimiter was a single quote, but double colon is now the preferred delimiter, in part because it's more readable to humans, and in part because it's more readable to emacs macros. It also makes C++ programmers feel like they know what's going on.)
Packages may be nested inside other packages: $OUTER::INNER::var. This implies nothing about the order of name lookups, however. All symbols are either local to the current package, or must be fully qualified from the outer package name down. For instance, there is nowhere within package OUTER that $INNER::var refers to $OUTER::INNER::var. It would treat package INNER as a totally separate global package.
Only identifiers starting with letters (or underscore) are stored in a package's symbol table. All other symbols are kept in package main. In addition, the identifiers STDIN, STDOUT, STDERR, ARGV, ARGVOUT, ENV, INC and SIG are forced to be in package main, even when used for other purposes than their built-in one. Note also that, if you have a package called m, s or y, then you can't use the qualified form of an identifier since it will be interpreted instead as a pattern match, a substitution, or a translation.
(Variables beginning with underscore used to be forced into package main, but we decided it was more useful for package writers to be able to use leading underscore to indicate private variables and method names.)
Eval()ed strings are compiled in the package in which the eval() was
compiled. (Assignments to $SIG{}, however, assume the signal
handler specified is in the C The value in each entry of the associative array is what you are
referring to when you use the *name notation. In fact, the following
have the same effect, though the first is more efficient because it
does the symbol table lookups at compile time:
Assignment to a symbol table entry performs an aliasing operation,
i.e.,
A
BEGIN
subroutine is executed as soon as possible, that is, the
moment it is completely defined, even before the rest of the containing
file is parsed. You may have multiple
BEGIN
blocks within a
file--they will execute in order of definition. Because a
BEGIN
block executes immediately, it can pull in definitions of subroutines
and such from other files in time to be visible to the rest of the
file.
An
END
subroutine is executed as late as possible, that is, when the
interpreter is being exited, even if it is exiting as a result of a
die() function. (But not if it's is being blown out of the water by a
signal--you have to trap that yourself (if you can).) You may have
multiple
END
blocks within a file--they wil execute in reverse
order of definition; that is: last in, first out (LIFO).
Note that when you use the
-n
and
-p
switches to Perl,
BEGIN
and
END
work just as they do in awk, as a degenerate case.
Perl modules are included by saying
For more information on writing extension modules, see
the perlapi manpage
and
the perlguts manpage
.
The module and its user have a contract, part of which is common law,
and part of which is "written". Part of the common law contract is
that a module doesn't pollute any namespace it wasn't asked to. The
written contract for the module (AKA documentation) may make other
provisions. But then you know when you use RedefineTheWorld that
you're redefining the world and willing to take the consequences.
The following programs are defined (and have their own documentation).
The following are popular C extension modules, which while available at
Perl 5.0 release time, do not come not bundled (at least, not completely)
due to their size, volatility, or simply lack of time for adequate testing
and configuration across the multitude of platforms on which Perl was
beta-tested. You are encouraged to look for them in archie(1L), the Perl
FAQ or Meta-FAQ, the WWW page, and even their authors before randomly
posting asking for their present condition and disposition. There's no
guarantee that the names or addresses below have not changed since printing,
and in fact, they probably have!
Symbol Tables
The symbol table for a package happens to be stored in the associative
array of that name appended with two colons. The main symbol table's
name is thus %main::, or %:: for short. Likewise the nested package
mentioned earlier is named %OUTER::INNER::.
local(*main::foo) = *main::bar; local($main::{'foo'}) =
$main::{'bar'};
You can use this to print out all the variables in a package, for
instance. Here is F
package dumpvar;
sub main::dumpvar {
($package) = @_;
local(*stab) = eval("*${package}::");
while (($key,$val) = each(%stab)) {
local(*entry) = $val;
if (defined $entry) {
print "\$$key = '$entry'\n";
}
if (defined @entry) {
print "\@$key = (\n";
foreach $num ($[ .. $#entry) {
print " $num\t'",$entry[$num],"'\n";
}
print ")\n";
}
if ($key ne "${package}::" && defined %entry) {
print "\%$key = (\n";
foreach $key (sort keys(%entry)) {
print " $key\t'",$entry{$key},"'\n";
}
print ")\n";
}
}
}
Note that even though the subroutine is compiled in package dumpvar,
the name of the subroutine is qualified so that its name is inserted
into package main.
*dick = *richard;
causes variables, subroutines and filehandles accessible via the
identifier richard to also be accessible via the symbol dick. If
you only want to alias a particular variable or subroutine, you can
assign a reference instead:
*dick = \$richard;
makes $richard and $dick the same variable, but leaves
@richard and @dick as separate arrays. Tricky, eh?
Package Constructors and Destructors
There are two special subroutine definitions that function as package
constructors and destructors. These are the
BEGIN
and
END
routines. The sub is optional for these routines.
Perl Classes
There is no special class syntax in Perl 5, but a package may function
as a class if it provides subroutines that function as methods. Such a
package may also derive some of its methods from another class package
by listing the other package name in its @ISA array. For more on
this, see
the perlobj manpage
.
Perl Modules
In Perl 5, the notion of packages has been extended into the notion of
modules. A module is a package that is defined in a library file of
the same name, and is designed to be reusable. It may do this by
providing a mechanism for exporting some of its symbols into the symbol
table of any package using it. Or it may function as a class
definition and make its semantics available implicitly through method
calls on the class and its objects, without explicit exportation of any
symbols. Or it can do a little of both.
use Module;
or
use Module LIST;
This is exactly equivalent to
BEGIN { require "Module.pm"; import Module; }
or
BEGIN { require "Module.pm"; import Module LIST; }
All Perl module files have the extension F<.pm>.
use
assumes this so
that you don't have to spell out "F
require Cwd; # make Cwd:: accessible
$here = Cwd::getcwd();
use Cwd; # import names from Cwd::
$here = getcwd();
require Cwd; # make Cwd:: accessible
$here = getcwd(); # oops! no main::getcwd()
Perl packages may be nested inside other package names, so we can have
package names containing ::. But if we used that package name
directly as a filename it would makes for unwieldy or impossible
filenames on some systems. Therefore, if a module's name is, say,
Text::Soundex, then its definition is actually found in the library
file FNOTE
Perl does not enforce private and public parts of its modules as you may
have been used to in other languages like C++, Ada, or Modula-17. Perl
doesn't have an infatuation with enforced privacy. It would prefer
that you stayed out of its living room because you weren't invited, not
because it has a shotgun.
THE PERL MODULE LIBRARY
A number of modules are included the the Perl distribution. These are
described below, and all end in F<.pm>. You may also discover files in
the library directory that end in either F<.pl> or F<.ph>. These are old
libaries supplied so that old programs that use them still run. The
F<.pl> files will all eventually be converted into standard modules, and
the F<.ph> files made by h2ph will probably end up as extension modules
made by h2xs. (Some F<.ph> values may already be available through the
POSIX module.) The pl2pm file in the distribution may help in your
conversion, but it's just a mechanical process, so is far from bullet proof.
Pragmatic Modules
They work somewhat like pragmas in that they tend to affect the compilation of
your program, and thus will usually only work well when used within a
use
, or
no
. These are locally scoped, so if an inner BLOCK
may countermand any of these by saying
no integer;
no strict 'refs';
which lasts until the end of that BLOCK.
Standard Modules
The following modules are all expacted to behave in a well-defined
manner with respect to namespace pollution because they use the
Exporter module.
See their own documentation for details.
Extension Modules
Extension modules are written in C (or a mix of Perl and C) and get
dynamically loaded into Perl if and when you need them. Supported
extension modules include the Socket, Fcntl, and POSIX modules.
ftp://ftp.ncsu.edu/pub/math/wsetzer/cursperl5??.tar.gz
It is currently in alpha test, so the name and ftp location may
change.
ftp.pasteur.fr:/pub/Perl/Sx.tar.gz