|
Appendix B |
|
|
|
Appendix B |
|
For simple programs, you can easily write your own Perl routines and subroutines. As the tasks to which you apply Perl become more difficult, however, sometimes you'll find yourself thinking, "someone must have done this already." You are probably more right than you imagine.
For most common tasks, other people have already written the code. Moreover, they've placed it either in the standard Perl distribution or in the freely downloadable CPAN archive. To use this existing code (and save yourself some time), you'll have to understand how to make use of a Perl library. This task was briefly discussed in Chapter 18, CGI Programming .
One advantage in using modules from the standard distribution is that you can then share your program with others without having to take any special steps. This statement is true because the same standard library is available to Perl programs almost everywhere.
You'll save yourself time in the long run if you get to know the standard library. No one benefits from reinventing the wheel. You should be aware, however, that the library contains a wide range of material. While some modules may be extremely helpful, others may be completely irrelevant to your needs. For example, some modules are useful only if you are creating extensions to Perl.
To read the documentation for a standard module, use the perldoc program (if you have the standard distribution), or perhaps your web browser on HTML versions of the documentation. If all else fails, just look in the module itself; the documentation is contained within each module in pod format. To locate the module on your system, try executing this Perl program from the command line:
perl -e "print \"@INC\n\""
You should find the module in one of the directories listed by this command.
Before we list the standard modules, let's untangle some terminology:
A package is a simple namespace management device, which allows two different parts of a Perl program to each have a (different) variable named
$fred
. These namespaces are managed with the
package
declaration, described in
Chapter 5
of
Programming Perl
.
A library is a set of subroutines for a particular purpose. Often the library declares itself a separate package so that related variables and subroutines can be kept together, and so that they won't interfere with other variables in your program. Generally, an old-style library used to be placed in a separate file, often with a name ending in
.pl
. The library routines were then pulled into the main program via the
require
function. More recently this older approach has been replaced by the use of
modules
(see next paragraph), and the term
library
often refers to the entire system of modules that come with Perl.
A module is a library that conforms to specific conventions, allowing the library routines to be brought into your program with the
use
directive at compile time. Module filenames end in
.pm
, because the
use
directive insists on that convention.
Chapter 5
of
Programming Perl
describes Perl modules in greater detail.
An extension is a combination of a module written in Perl and a library written in C (or C++). On Win32 systems, these extensions are implemented as dynamic-link libraries and have a
.pll
file extension. Extension modules are used just like modules - with the
use
directive at compile time. The case is important here: it doesn't necessarily need to match the filename that the package is stored in, but should match the case used in the package declaration.
A pragma is a module that affects the compilation phase of your program as well as the execution phase. Think of it as something that contains hints to the compiler. Unlike other modules, pragmas often (but not always) limit the scope of their effects to the innermost enclosing block of your program (that is, the block enclosing the pragma invocation). The names of pragmas are by convention all lowercase.
|
|
|
|
| A.18 Chapter 19, OLE Automation |
|
B.2 Standard Modules |