Perl modules are really a specialized form of Perl packages . In this Item we will discuss packages, then the specializations that make a package a module.
A Perl package is a namespace. It's that simple. Whether or not you are familiar with packages, if you have written a Perl program, you have already used at least one: the main package. By default, all variables created in a Perl program are part of the main package.
To refer to a variable in another package, prefix its name with the package name, followed by two colons (called a " qualified name"). Two colons without any package name is shorthand for the main package:
The package directive changes the current default package. It remains effective until the end of the current block or file:
Continued from above:
Packages can be nested. For example, $foo::bar::bletch is a variable named bletch nested inside a package named bar inside a package named foo . However, qualified names always must appear in fullyou cannot use $bar::bletch to refer to the above variable bletch even if the default package is foo .
Packages are implemented as symbol tables, which are just ordinary Perl hashes with a special purpose (see Item 55). The name of a package symbol table is the package name followed by two colons, for example %foo:: and %:: (the main package's symbol table). Although occasions when you should directly manipulate symbol tables are rare, you can, for example, import names from one package into another:
A possibly unexpected side effect of this kind of manipulation is that it aliases variables in one package to another. In the example above, $main::a and $foo::a now refer to the same thing:
Continued from above:
You can see more of this type of Perl "magic" in Item 55. Remember that my variables are never in any package (see Item 23).
A Perl module is a package that meets certain requirements. To be a Perl module, a package must:
The purpose of a module is to implement reusable, modular functionality. Generally , modules define subroutines and/or Perl classes (see Item 49). Modules can also define variables (scalars, arrays, etc.). They can perform actions at startup and can even alter language syntax or semantics (see Item 37).
Modules are generally stored in a library directory that is accessible via Perl's default include path (see Item 43). Exactly what that location is will vary depending upon your installation, but a typical location would be something like /usr/local/lib/perl5/ .
Modules can be nested. Nested modules are stored in a nested directory/file structure. For example, given an installation whose libraries are stored in /usr/local/lib/perl5/ , the File::Basename module will most likely be found in /usr/local/lib/perl5/File/Basename.pm .
It's easy to put a module to work for you. Just "use" the modulewith Perl's use directive. The use directive loads a module and imports the subroutines and other symbols that are exported from that module by default:
For example, suppose you have just learned about the File::Basename module. Suppose you would like to use the dirname subroutine that it defines. Here's one possibility:
The use directive can take a list of arguments. These are passed to the module's import method, and, assuming that the module's import method has the usual semantics, this list should be a list of symbolssubroutine names and the likethat are to be imported into the current package. For example, if you wish to import only dirname and basename from File::Basename , you can invoke it as:
use File::Basename qw(dirname basename);
If you wish to import no symbols at all, pass an explicit empty list:
use File::Basename ();
Remember that Perl doesn't prevent you from accessing symbols (other than my variables) that are not in the current package. If you use a module but choose not to import any symbols from it, you can always refer to them with their fully qualified names: