In the last chapter, you were introduced to object-oriented programming. Along the way, you learned some aspects of programming with Modules although you may not have realized it. The shortest definition of a module is a namespace defined in a file.
For example, the English module is defined in the English.pm file and the Find module is defined in the Find.pm file.
Of course, modules are more than simply a namespace in a file. But, don't be concerned -- there's not much more.
Perl 4, the last version of Perl, depended on libraries to group functions in units. 31 libraries shipped with Perl 4.036. These have now been replaced with a standard set of modules. However, the old libraries are still available in case you run across some old Perl scripts that need them.
Libraries and modules are generally placed in a subdirectory called Lib.
For examole in a typical machine, the library directory is
c:\perl5\lib. If you don't know what your library
directory is, ask your system administrator. Some modules are placed in
subdirectories like Lib/Net or Lib/File.
The modules in these subdirectories are loaded using the subdirectory name, two colons, and the module name. For example,
Net::Ping or File::Basename.
Libraries are made available to your script by using the require compiler directive.
Directives may seem like functions, but they aren't. The difference is that compiler directives are carried out when the script is compiled and functions are executed while the script is running.
Some modules are just collections of functions -- like the libraries -- with some "module" stuff added. Modules should follow these guidelines:
Modules are loaded by the use directive, which is similar to require except it automates the importing of function and variable names.
Modules that are simply a collection of functions can be thought of as classes without constructors. Remember that the package name is the class name. Whenever you see a package name, you're also seeing a class-even if none of the object-oriented techniques are used.
Object-oriented modules keep all function and variable names close to the vest-so to speak. They are not available directly, you access them through the module name. Remember the Inventory_item->new() notation?
However, simple function collections don't have this object-oriented need for secrecy. They want your script to directly access the defined functions. This is done using the Exporter class, @EXPORT, and @EXPORT_OK.
The Exporter class supplies basic functionality that gives your script access to the functions and variables inside the module. The import() function, defined inside the Exporter class, is executed at compile-time by the use compiler directive. The import() function takes function and variable names from the module namespace and places them into the main namespace. Thus, your script can access them directly.
Note I can almost hear your thoughts at this point. You're thinking, "The exporting of function and variable names is handled by the import() function?" Well, I sympathize. But, look at it this way: The module is exporting and your script is importing.
You may occasionally see a reference to what may look like a nested
module. For example, $Outer::Inner::foo.
This really refers to a module named Outer::Inner,
so named by the statement: package Outer::Inner;.
Module designers sometimes use this technique to simulate nested
modules.