Summation

Writing Perl Modules for CPAN by Sam Tregar from APress, is a meta-perl book. Not so much a book about writing perl code, but a book about the process of writing perl code. More importantly, a book about publishing perl code---and best of all written by someone who has “been there, done that!” If you have ever thought to write the next great module this book represents the required minimum. If you did nothing else but use this as a check list you would be way ahead of the game.

Recommended.

Audience: intermediate to advanced.

The Details

My first reaction on seeing a reference to this book was an instant order without regard to content. Being a biblioholic---this is an admittedly normal reaction, but I was also reacting to the notion that “it's about time! Someone must have written all of this stuff down somewhere, this must be it!!” As anyone who has survived the CPAN process can tell you, you need all of the help you can get. Writing Perl Modules for CPAN has just become part of that “help”---save yourself some time, buy it and use it as a starting point. You will still need help, some from CPAN, some from various lists, some from here at PM, that won't change---you'll just need less!

The book divides rather neatly into two parts; CPAN and module mechanics are the subject of the first half, inspiration and advanced topics, the subject of the second. The first six break down pretty much like this:

CPAN

This chapter is a combination of history and physical (all right!--would you belive virtual?) layout. We constantly refer to CPAN, but now you can actually talk about it accurately! Here you learn about a number of useful things not all of which are that obvious. Take DSLIP for instance. DSLIP stands for Development State, Support Level, Language Used, Interface Style and Public License. Every module has one! This is sort of like a de-coder ring you get in a box of Cracker-Jacks (do they still do that?) Can't find what (or who) you are looking for? Consider this:

Upon entering the Modules By Author view, you see a directory listing with what appears to be a directory for every author on CPAN. This is misleading---the list you're seeding is a relic of the past. When CPAN started every author received an entry in this directory, but there's a limit to how many subdirectories a single directory can efficiently contain. These days there are far too many authors on CPAN to house them all in one directory, so CPAN switched to a multilevel hierarchy for storing author directories, which is used today.

Knowing this probably won't get you an 'A' on Monday's test, but it sure beats wandering around looking for breadcrumbs!

The material on installing CPAN Modules should probably be transcribed directly into PM's beginner's tutorial. It covers both of the two major 'assisted' methods, CPAN.pm and ppm as well as a blow-by-blow description of doing it the 'hard way'. Want to know about 'nmake'? Look here.

Perl Module Basics

This chapter on modules will start you from pretty much zero on the subject of modules. While I would assume that the intended audience of the book pretty much understands the concept, it never hurts to review. For that matter a clear picture of the basics is always a good thing™ For instance, even though it has been mentioned in other books more than once, here is a clear explanation of use:

Since use is just a way of doing a require operation and an import operation at compile time, use can be defined in terms of require using BEGIN:

BEGIN { require File::Find; import File::Find; }

And frankly, the more people who understand “How Perl Finds Modules” the fewer answers will be needed on the support lists. Although the exigencies of ISPs wary of modules are enough to cause us all heartburn, after this portion of the chapter you should be able to continue without problem.

After getting some of this meta-module material out of the way this chapter really takes off. In the space of some 33 pages, the author takes you from the first use of the word package through the ins and outs of tied-overloaded methods! Quite a journey no matter what the route!

Module Design and Implementation

As you might expect from any chapter with the word 'Design' in the title, this chapter contains a good deal of what might be more generically called philosophy. Given that we are all victim to a vast number of things built without regard to any 'design', philosophical or not, any material directed to folks about to build things that covers design can't help but be a good thing. Besides how can you not like a chapter that has a section entitled “Check Your Slack”? Seriously though, the points raised and the methods suggested in this chapter are really quite solid. If you aren't doing it this way, make sure that you have a good reason! As a taste, here are the section titles:

Design a good interface, and everything else is negotiable. If your first pass at the implementation is flawed, no big deal; you improve it, and your users get a painless upgrade. Design a bad interface, and your module is doomed to uselessness. It doesn't matter how fantastic your implementation is---no one can figure out how to use it and no one will.

Yes indeedy, ladies and gentlemen, everything is an interface and we are all users! How many times have we all been burned by a library or a module or an API or--- well fill in the blank, you know what I mean. To see well written material on this problem does me a world of good. And covers some of the best advice in the book as well!

CPAN Module Distributions

I would hope that most of the readers have installed a module before---doesn't matter, the author takes you through the process step by step with an real example from CPAN. It won't hurt you to read about it no matter what your level of experience is. He does this to make the point that the process is actually a minor miracle---it works, it works pretty much regardless of platform. No it is not 100%---little is! But for the most part, it works! This chapter then proceeds to explain just why this is possible. Again with the section titles:

Ada Lovelace for the palindrome
Albert Einstein for having smelly feet
Alfred Nobel for his contribution to battlefield science
Burkhard Heim for providing the missing link between science and mysticism
Claude Shannnon for riding a unicycle at night at MIT
Donald Knuth for being such a great organist
Edward Teller for being the template for Dr. Strangelove
Edwin Hubble for pretending to be a pipe-smoking English gentleman
Erwin Schrödinger for cruelty to cats
Hedy Lamarr for weaponizing pianos
Hugh Everett for immortality, especially for cats
Isaac Newton for his occult studies
Kikunae Ikeda for discovering the secrets of soy sauce
Larry Wall for his website
Louis Camille Maillard for discovering why steaks taste good
Marie Curie for the shiny stuff
Nikola Tesla for the cool cars
Paul Dirac for speaking one word per hour when socializing
Richard Feynman for his bongo skills
Robert Oppenheimer for his in-depth knowledge of the Bhagavad Gita
Rusi P Taleyarkhan for Cold Fusion
Sigmund Freud for his Ménage ā trois
Theodor W Adorno for his contribution to the reception of jazz
Wilhelm Röntgen for the foundations of body scanners
Yulii Borisovich Khariton for the Tsar Bomba
Other (please explain why)