main. You can switch namespaces
using the package declaration. The scope of the package declaration is
from the declaration itself to the end of the enclosing block (the same
scope as the
local()
operator). Typically it would be the first
declaration in a file to be included by the
require
operator. You can
switch into a package in more than one place; it merely influences which
symbol table is used by the compiler for the rest of that block. You can
refer to variables and filehandles in other packages by prefixing the
identifier with the package name and a double colon:
$Package::Variable. If the package name is null, the main package
as assumed. That is, $::sail is equivalent to $main::sail.
(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 because 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 main package. Qualify the signal handler
name if you wish to have a signal handler in a package.) For an
example, examine perldb.pl in the Perl library. It initially switches
to the DB package so that the debugger doesn't interfere with variables
in the script you are trying to debug. At various points, however, it
temporarily switches back to the main package to evaluate various
expressions in the context of the main package (or wherever you came
from). See
the perldebug manpage
.
%main::, or %:: for short. Likewise the nested package
mentioned earlier is named %OUTER::INNER::.
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:
You can use this to print out all the variables in a package, for instance. Here is dumpvar.pl from the Perl library:
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.
Assignment to a symbol table entry performs an aliasing operation, i.e.,
causes variables, subroutines and file handles 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:
makes $richard and $dick the same variable, but leaves @richard and @dick as separate arrays. Tricky, eh?
BEGIN and END
routines. The sub is optional for these routines.
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 will 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
or
This is exactly equivalent to
or
All Perl module files have the extension .pm. use assumes this so that you don't have to spell out "Module.pm" in quotes. This also helps to differentiate new modules from old .pl and .ph files. Module names are also capitalized unless they're functioning as pragmas, "Pragmas" are in effect compiler directives, and are sometimes called "pragmatic modules" (or even "pragmata" if you're a classicist).
Because the
use
statement implies a BEGIN block, the importation
of semantics happens at the moment the
use
statement is compiled,
before the rest of the file is compiled. This is how it is able
to function as a pragma mechanism, and also how modules are able to
declare subroutines that are then visible as list operators for
the rest of the current file. This will not work if you use
require
instead of
use
. Therefore, if you're planning on the module altering
your namespace, use
use
; otherwise, use
require
. Otherwise you
can get into this problem:
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 Text/Soundex.pm.
Perl modules always have a .pm file, but there may also be dynamically linked executables or autoloaded subroutine definitions associated with the module. If so, these will be entirely transparent to the user of the module. It is the responsibility of the .pm file to load (or arrange to autoload) any additional functionality. The POSIX module happens to do both dynamic loading and autoloading, but the user can just say use POSIX to get it all.
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.
which lasts until the end of that BLOCK.
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 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 with 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!
It is currently in alpha test, so the name and ftp location may change.