A Perl module is a discrete component of software for the Perl programming language. Technically, it is a particular set of conventions for using Perl's package mechanism that has become universally adopted.
Contents
- Examples
- Procedural example
- Object oriented example
- Perl packages and namespaces
- Packages and modules
- References
A module defines its source code to be in a package (much like a Java package), the Perl mechanism for defining namespaces, e.g. CGI or Net::FTP or XML::Parser; the file structure mirrors the namespace structure (e.g. the source code for Net::FTP is in Net/FTP.pm). Furthermore, a module is the Perl equivalent of the class when object-oriented programming is employed.
A collection of modules, with accompanying documentation, build scripts, and usually a test suite, compose a distribution. The Perl community has a sizable library of distributions available for search and download via CPAN.
Perl is a language allowing many different styles of programming. You're as likely to find a module written in a procedural style (for example, Test::Simple) as object-oriented (e.g. XML::Parser), both are considered equally valid according to what the module needs to do. Modules might also be used to mixin methods (DBIx::Class) or be a pragma (strict.pm) which has an effect immediately upon being loaded. Modules can even be used to alter the syntax of the language. The effect of Perl modules are usually limited to the current scope in which it was loaded.
It is common for Perl modules to have embedded documentation in Perl's Plain Old Documentation format. POD imposes little structure on the author. It is flexible enough to be used to write articles, web pages and even entire books such as Programming Perl. Contrast with javadoc which is specialized to documenting Java classes. By convention, module documentation typically follows the structure of a Unix man page.
The language of Perl is defined by the single implementation (referred to as "perl") and is added to (and in rare occasions taken away from) each new release. For this reason it is important for a module author to be aware what features they're making use of and what the minimum required version of perl is. The code on this page requires perl 5.6.0 which is considered rather old by now.
Examples
What follows are examples of "Hello, World" implemented in different styles of modules. It must be understood that a module is not necessary in Perl; functions and code can be defined and used anywhere. This is just for example purposes. Contrast with Java where a class is always necessary. A real "Hello, World" function would be written like so:
or simply printed in one line:
Procedural example
Here is "Hello, World" implemented as a procedural module with a customizable target for the greeting, just to make things interesting. Also included is a short script to illustrate the module's use.
Object-oriented example
Here's an example of the same thing done in an object-oriented style. The advantage of an OO module is that each object can be configured independently from other objects.
Perl packages and namespaces
A running Perl program has a built-in namespace called "main", which is the default name. For example, a subroutine called Sub1 can be called as Sub1() or main::Sub1(). With a variable the appropriate sigil is placed in front of the namespace; so a scalar variable called $var1 can also be referred to as $main::var1, or even $::var1. Other namespaces can be created at any time.
Package declarations apply package scope till the next package declaration or the end of the block in which the declaration is made.
Packages and modules
Conventionally, namespaces are associated with modules; in practice, there is usually one namespace per module and vice versa, but that's not mandated by the language. For example, the 'standard' module CGI.pm has the following declaration at its top:
This module, and its functionality, would commonly be invoked as follows:
A 'missing' subroutine could be added from the using program's namespace.
and invoked as below:
However, though technically feasible, that would be dubious programming practice. You might just as well define the sub in the calling namespace, and call it from that namespace.