[ Team LiB ] |
13.3 The Prototype Module ItselfNow you come to the most important part of the distribution: the module itself. Finally, actual code: $ cat Maps.pm package Island::Plotting::Maps; It looks good so far. The module automatically starts with an appropriate package directive. Following that, you see: use 5.008; use strict; use warnings; Now you're declaring that the module is compatible with Perl 5.8.0 or later and that the compiler restrictions and warnings are enabled automatically. Good practices are encouraged here. Obviously, you're free to delete or modify anything inappropriate. require Exporter; our @ISA = qw(Exporter); These lines support the import method call needed to make use work. This is fine for a nonobject-oriented module, but for an object-oriented module inheriting from a parent (base) class, you'll want to replace them with: use base qw(Our::Parent::Class); Resulting in more Exporter control: our %EXPORT_TAGS = ( 'all' => [ qw( ) ] ); our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } ); our @EXPORT = qw( ); Every symbol you wish to possibly import as a result of the use operation should be placed into the first qw( ) list. This lets you say: use OurModule qw(:all) to get all possible symbols.[6]
Every symbol you wish to export by default on a missing import list should go into the last qw( ). (Any symbol in the @EXPORT list is automatically a member of the @EXPORT_OK list, but you'll want to list it again it the first qw( ) list so it comes in via the :all method.) Recall from Chapter 12 that a typical object-oriented module exports nothing because the interface is entirely through class method calls and instance method calls, neither of which require subroutines in the invoker's package. Next, you'll see the version number: our $VERSION = '0.01'; This version number is important for many reasons:
Generally, you can start with the 0.01 given by the template and increase it consistently with each new test release. Often, you can coordinate this version number with some source code control system.[7]
Now you're past the header information and down to the core of your module. In the template, it is indicated by a simple comment: # Preloaded methods go here. What? You didn't think the h2xs tool would even write the module for you, now did you? Anyway, this is where the code goes, usually as a series of subroutines, possibly preceded by some shared module data (using my declarations), and perhaps a few package variables (using our declarations in recent Perl versions). Following the code, you'll find your necessary true value: 1; so the require (inside the use) doesn't abort. |
[ Team LiB ] |