WebReference.com - Perl Module Primer (5/5)
Perl Module Primer
So, where do you go from here? Here's a brief list of topics, presented in no specific order, that you may now want to pursue in search of further module knowledge.
- Object Oriented Design
- We mentioned at the outset that you didn't need to be an OOP guru to create modules. But the fact of the matter is, having worked your way through this tutorial you already know a good portion of what you need to know to implement an object oriented module. For example, in Perl OOP, packages are classes; and a reference (such as a hash reference) becomes an object when it is blessed into a class. From then on, all of the methods (i.e., the sub routines) that exist in that class (i.e. package) are accessible through the object itself; with the object automatically passed to the method as a reference (so you can access the object from within the method). And we saw a simplified use of inheritance via the @ISA variable on the bottom of the previous page. Once you've coded up a module or two of your own (or even before then, if you have an OOP background and/or are particular adventurous), I encourage you to have a look at the bless command and the general definition and use of objects in Perl.
- Document Your Work!
- Modules are intended to be encapsulated, functional collections of code. But even if your module is perfectly designed, it will be useless if the next person who comes along doesn't know what functions your module contains or how to access and use them. An excellent way to make this type of information available to everyone who wants to get it is to use Plain Old Documentation, or POD. POD statements are embedded within your module itself, and can be automatically read by specific perl utilities such as perldoc allowing users to easily see what your module does and how it does it (and anything else, within reason, that you want to tell the would-be user).
- AUTOLOAD and AutoLoader
- Perl provides a mechanism such that if the user calls a routine that doesn't actually exist within a package, then a specific routine, called AUTOLOAD is run instead. The AutoLoader module takes this concept a step further, allowing you to separate chunks of your module into smaller components that can then be pulled into the script as they are needed, as opposed to loading your entire module in every time it is used. This can be helpful when your modules get very large, as it can reduce the overall memory requirements of the calling application.
I hope you've found this brief tutorial to be helpful. Good luck in your efforts to build your own module-based projects!
Created: April 7, 2005
Revised: April 7, 2005