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, "Modules", and in Chapter 12, "Objects".
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, "Modules" 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, "Objects".
A pragma is just a special module that twiddles Perl's internal knobs. See Chapter 31, "Pragmatic Modules".
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.
Copyright © 2002 O'Reilly & Associates. All rights reserved.