 | Chapter 7 |  |
| Chapter 7 | |
Over the years, Perl has evolved from a utilitarian scripting tool into a sophisticated object-oriented programming language. Many people continue to use Perl just for simple scripts, and Perl will continue to make simple tasks easy. However, Perl can also make difficult tasks possible, by writing reusable code and using object-oriented programming techniques.
This chapter explains what Perl modules are and how to use them in your programs. Modules are written to accomplish tasks that either aren't implemented by Perl's built-in functions, or that could be done better. We say modules are "reusable" because anyone who needs to accomplish the same task can use that module instead of writing the code from scratch. As you write more and more Perl code, you'll undoubtedly find yourself using many of the modules other Perl programmers have provided. You may also find yourself writing modules and making them available for others to use.
The remainder of this book describes a significant portion of the
functionality that's present in publicly available Perl modules.
You'll find that a number of standard or core modules are
distributed with Perl; many of these modules are discussed in Chapter 8, Standard Modules. Scores of other modules are available on CPAN, and virtually any
task you'd like to accomplish in Perl is implemented in a module found
there. For unbundled modules, you'll need to install the module on
your system, and then integrate it into your program with the
use function.
The use function is often the key to working with modules. For
example, to bring the functionality of the popular CGI module into
your program, you need to install the CGI.pm module (the
.pm stands for Perl module) and put this line near the top of your
program:
Now your program can make use of the many functions and variables made available by the CGI module.use CGI;
Packages (from which modules are built) are also the mechanism by which Perl's object-oriented features are implemented. But object-oriented programming isn't for everyone, and there's nothing in packages that forces the programmer to work with the object-oriented paradigm.
A namespace does what it says: it stores names (or identifiers), including names of variables, subroutines, filehandles, and formats. Each namespace has its own symbol table, which is basically a hash with a key for each identifier.
The default namespace for programs is main, but you may
define other namespaces and variables and use them in your program.
Variables in different namespaces can even have the same name, but
they are completely distinct from one another.
In Perl, a namespace is held in a package. By convention, package names start with a capital letter, and you should follow that convention when you create your own packages.
Each package
starts with a package declaration. The package call
takes one argument, the name of the package. Within the scope of a
package declaration, all regular identifiers are created within that
package (except for my variables).
From inside one package, you can refer to variables from another
package by "qualifying" them with the package name. To do this, place
the name of the package followed by two colons (::) before the
identifier's name, i.e., $Package::varname.
If the package name is null, the main package is assumed. For
example, $var and $::var are the same
as $main::var.
Packages may be nested inside other packages. However, the package name
must still be fully qualified. For example, if the package
Province is declared inside the package Nation, a
variable in the Province package is called as
$Nation::Province::var. You cannot use a "relative" package
name such as $Province::var within the Nation package
for the same thing.
The default main namespace contains all
other packages within it.
|  | |
| III. Modules |  | 7.2 Modules |