This is part 2 of a series on Perl, intended for experienced software developers.
Re-learning Perl has not been easy.
It’s easy to find instructions online to create modules. You can even export functions into the calling program’s namespace.
It’s easy unless you
use strict; and my policy, and the company’s, is to
use strict; and
So here are the steps required to make functions available in the calling program’s namespace, with warnings on, and strict on:
Start your module file with the strict and warnings lines:
use strict; use warnings;
Declare the name of your package:
This line must appear before the Exporter lines. It must also match the name of the file, in other words, the file must be called
FileInfo.pm . The “.pm” extension is the normal extension for perl modules, the only extension supported by shortcuts like this way of naming the package.
Setup the Exporter module to export your package and the public functions in it.
use Exporter qw(import); our @ISA = qw(Exporter); our @EXPORT_OK = qw(readFile);
The first two lines here are generic, copy and past them in your module.
EXPORT_OK is an array, a list of functions in this module that you want to use in the calling Perl code. In
EXPORT_OK, do not include private functions that are used by your public functions and are not intended for use from the calling program.
q(), qq(), and qw() are three of several ways in Perl to create a quoted string. q() and qq()are used primarily to quote a string that contains both single and double quotes. q() strings do not allow expansion of variables inside the string (and maybe some other things), like a single-quoted string. qq() allows expansion of variables and back-slashed caracters. For instance
qq($foo\n)will have a line end at the end, after the contents of
qw() is a bit different. “qw” stands for “quoted words”. Each of the space-separated words inside the brackets is a separate element of an array. It’s traditional to define your arrays this way in module definitions. I haven’t tried to make other arrays work.
There are two arrays you can use to share your functions.
EXPORTshoves its funtion names into the namespace of the calling code.
EXPORT_OKonly puts in what you ask for with a list at the end of the
usestatement. Since we are using
EXPORT_OK instead of
EXPORT , you must list in the calling program which functions you want to have in your namespace. If the name conflicts with a function name from another package, you can always call it using the name of the package the function is in.
Example: Instead of calling the
readFile($file_name), you would use:
There is one more thing to do in your module to make it standard. Well, one thing apart from adding some functions and data.
You need to end it with:
Yes, that’s a one, with a semi-colon after it to mark the end of the statement. When the module ends, the last thing the compiler will see is “truth”, which means it has really reached the end of the module and all is right with the world. No guesses as to whether it missed something!
Now, let’s see how to include your beautiful module in your other code. Put this line near the top of your file, with all the other use statements.
use FileInfo qw(FileInfo);
This means that you are trying to use FileInfo.pm, and want to import the “readFile” function into your namespace so you don’t have to specify what module it comes from, every time you use it.
And that’s all there is to creating a module.
But wait! There’s more!
You can also put some POD (Plain old documentation) after the end of the module! But that’s a possibility for another blog. You don’t need that yet. And you may prefer not to use that way of writing documentation. It’s a bit old-fashioned, with an inheritance far preceding Perl, and very verbose.
Thanks for reading.
Let me know in the comments if I confused you or I missed something, or even if I got it wrong. Typos are a definite risk!
Follow me here and on Medium, if you are interested in more articles on learning languages, not just Perl.
Originally published on Medium.