The standard Perl distribution contains much more than just the perl executable that executes your scripts. It also includes hundreds of modules filled with reusable code. Because the standard modules are available everywhere, if you use one of them in your program, you can run your program anywhere Perl is installed, without any extra installation steps.
Before we enumerate these modules in the following chapters, let's review a bit of the terminology we've been splattering about.
A namespace is a place to keep names so they won't be confused with names in other namespaces. This leaves you with the simpler problem of not confusing the namespaces themselves. There are two ways to avoid confusing namespaces with each other: give them unique names, or give them unique locations. Perl lets you do both: named namespaces are called packages and unnamed namespaces are called lexical scopes. Since lexical scopes can be no larger than a file, and since the standard modules are file-sized (at minimum), it follows that all module interfaces must make use of named namespaces (packages) if they're to be used by anyone outside the file.
A package is Perl's standard
mechanism for declaring a named namespace. It's a simple
mechanism for grouping together related functions and variables.
Just as two directories can both contain a (different) file
named fred, two different parts of a Perl
program can each have its own $fred
variable
or &fred
function. Even though these
variables or functions seem to have the same name as one
another, those names reside in distinct namespaces managed by
the package
declaration. Package names are
used to identify both modules and classes, as described in Chapter 11, and in Chapter 12.
The term library is unfortunately rather overloaded in Perl culture. These days we normally use the term to mean the entire set of Perl modules installed on your system.
Historically, a Perl library was also a single file
containing a collection of subroutines sharing some common
purpose. Such a file often has the file extension
.pl, short for "perl library". We still use
that extension for random bits of Perl code that you pull in
with do
FILE
or with require
. Although it's not a
full-fledged module, a library file typically declares itself to
be in a distinct package so related variables and subroutines
can be kept together and don't accidentally interfere with other
variables in your program. There is no mandatory extension;
others besides .pl sometimes occur as
explained later in this chapter. These simple, unstructured
library files have been largely superseded by the module.
A Perl module is a library file that
conforms to certain specific conventions that allow one or more
files implementing that module to be brought in with a single
use
declaration at compile time. Module
filenames must always end in .pm, because
the use
declaration assumes it. The
use
declaration will also translate the
package separator :
: to whatever your
directory separator is, so that the directory structure in your
Perl library can match your package structure. Chapter 11 describes how to
create your own Perl modules.
A class is just a module that implements methods for objects associated with the module's package name. If you're interested in object-oriented modules, see Chapter 12.
A pragma is just a special module that twiddles Perl's internal knobs. See Glossary.
An extension is a Perl module that, in addition to loading a .pm file, also loads a shared library implementing the module's semantics in C or C++.
A Perl program is code designed to be run as an independent entity; also known as a script when you don't want anyone to expect much from it, an application when it's big and complicated, an executable when its caller doesn't care what language it was written in, or an enterprise solution when it costs a fortune. Perl programs might exist as source code, bytecode, or native machine code. If it's something you might run from the command line, we'll call it a program.