|
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 |