Canned Perl - Using and enjoying Perl Modules

A simple guide to creating your own simple Perl modules.

In the early unix days, a popular Unix tool was called the “Swiss Army Knife” because of it's extreme flexibility and usefulness. Sometime later another well-known Unix person extended the metaphor to the Perl language by calling it the “Swiss Army Chainsaw”, implying that it was extremely powerful, but noisy, ugly and tended to belch noxious fumes. Perl fans immediately adopted the epithet as a badge of pride.

Perl is extremely powerful. Many aspects of Perl contribute to that power. One of the most important aspects is the Comprehensive Perl Archive Network (CPAN) where Perl fans can contribute bits of code to be reused by others. Many thousands of contributions are in the archive. Almost any complex function one can desire may be found there, enabling building complex programs in record time by simply incorporating a few modules.

In the demonstration program “MusicL.pl” we incorporate a number of such modules. The module Tk gives us the graphical toolkit for GUI widgets. The module Balloon lets us place tooltips in the GUI. The module MP3::TAG let's us easily manipulate MP3 tags. Finally, File::copy::Vigilant let's us easily perform file copies and moves.

Many of these functions are simple bits of code we could easily write ourselves. How hard could it be, for example, to copy a file? That said, there are many good reasons for using other people's modules.

First, it saves time. Even as simple a function as copying a file takes a little time to write and probably more time to debug. Second, it encapsulates functions and processes away from the mainstream of the program, simplifying our overall logic. Thirdly, it makes for easier debugging. Whenever contemplating any new function in a program, one should always give the CPAN a scan for useful modules. Never write any code you can find already written.

Modularity is an important concept in large programs. Keeping variables local, avoiding use of globals wherever possible and so on are important factors in writing code that is readable and maintainable.

One can always abstract bits of code into subroutines. For example, in MusicL, we place the logic that splits a long filename into MP3 tags into a subroutine we call “Song_Split”. There are numerous such subroutines, from drawing dialog boxes to validating fields. Such subroutines are, in a sense, tiny Perl modules that serve to encapsulate functionality. Understanding and using subroutines is important to writing maintainable Perl.

An experienced programmer will naturally build a “library” of favorite subroutines that will be reused in many different programs. Pasting these into a program, and then tweaking each instance for that program works, but one soon finds dozens of slightly different versions of the same program.

One way to avoid this is to build a collection of subroutines into a common text file and include that text file into many different programs, generalizing each subroutine to work across all programs. A better way is to write your own custom modules. If a module proves really useful, it can be contributed to the CPAN for others to use, “giving something back” to the Perl community.

At first glance, the inexperienced programmer might think perl modules are a bit of a “black art”. That is not really true, and we will show you how to make your own in just a few steps.

We're going to create a sample module. We will call it zModule, and place it in a file named zModule.PM. Our module has five parts, or steps.

The first step is defining the name space. This occurs in the package name, Package zModule. The namespace must be unique.

package zModule;

use strict;

use Exporter;

our $VERSION = 0.01;

our @ISA = qw(Exporter);

our @EXPORT = (); # Export Nothing by default

# Export functions on demand

our @EXPORT_OK = qw(rev1 map1);

our %EXPORT_TAGS = ( DEFAULT => [qw(&rev1)],

Both => [qw(&rev1 &map1)]);

# This subroutine just reverses things

sub rev1 { return reverse @_ }

# This one Uppercases things

sub map1 { return map{ uc }@_ }

1; # Return a TRUE value so loader

# knows load was successful

Part two involves strict error checking and variable declarations. While Perl will allow for sloppy “quick and dirty” code, anything more than a throw-away program really must be more tightly defined, or you quickly build something that is a bug-ridden, unmaintainable mess. Strict is your friend! An annoying friend, but a good one. It can be tempting to disable strict when it becomes annoying, but trust me, you do not want to define yourself debugging a 1000 line program that was written without strict. Each variable used is defined using the “our” alias declaration.

Part four, the Exporter simply invokes the logic necessary to use our module in another program. Note that we set things up so we export nothing by default, but rather only export our functions on demand.

Part five is the actual code we want in the module, written as subroutines. In our example, we create two very simple subroutines, one reverses the order of any text passed to it, the other converts it to uppercase.

The module is closed out with a True return value. This is provided simply so that the loader knows a load was successful.

#!/usr/bin/perl -w

use strict;

my @list = qw (P e r l – M o d u l e s – R u l e !);

use zModule qw(:Both);

print rev1(@list),"\n";

print map1(@list),"\n";

Having built our test module, let us now build a program to use it. Our demonstration program also uses strict (of course) and invokes our zModule to call two functions. Our data consists of a space delimited array of letters. We save our program as zTest.pl, and when we run it, we see the first subroutine call returns the text in reverse order, and the second call returns it as all caps.

$ perl zTest.pl

!eluR-seludoM-lrPe

PERL-MODULES-RULE!

$

Simple, huh? With nothing more than this simple example, even a relative neophyte programmer can write and use Perl Modules. This paper barely scratches the surface of the topic, and the user is urged to experiment and explore the subtleties of the process. But more importantly, the user is urged to use modules to keep your code, well, modular.