Learning Perl Objects, References amp;amp; Modules [Electronic resources] نسخه متنی

2.4 Using require

Suppose
navigate.pl itself also pulls in
drop_anchor.pl for some common navigation task.
You'll end up reading the file once directly, and
then again while processing the navigation package. This will
needlessly redefine drop_anchor( ). Worse than
that, if warnings are enabled,[5] you'll get a
warning from Perl that you've redefined the
subroutine, even though it's the same definition.

[5] You
are using warnings, right? You can enable them
with either -w or use
warnings;.

What
you need is a mechanism that tracks what files have been brought in
and bring them in only once. Perl has such an operation, called
require. Change the previous code to simply:

require "drop_anchor.pl";
require "navigate.pl";

The require operator
keeps track of the files it has read.[6] Once a file has been processed
successfully, any further require operations on
that same file are simply ignored. This means that even if
navigate.pl contains require
"drop_anchor.pl", the
drop_anchor.pl file is brought in exactly once,
and you'll get no annoying error messages about
duplicate subroutine definitions (see Figure 2-2).
Most importantly, you'll also save time by not
processing the file more than once .

[6] In the
%INC hash, as described in the entry for
require in the perlfunc
documentation.

Figure 2-2. Once the drop_anchor.pl file is brought in, another attempt to require the file is harmless

The require operator also has two additional
features:

Any syntax error in the
required file causes the program to die, thus the
many die $@ if $@ statements are unnecessary.

The last expression evaluated in the file must return a true value.

Because of the second point, most files evaluated for
require have a cryptic 1; as
their last line of code. This ensures that the last evaluated
expression is in fact true. Try to carry on this tradition as well.

Originally,
the mandatory true value was intended as a way for an included file
to signal to the invoker that the code was processed successfully and
that no error condition existed. However, nearly everyone has adopted
the die if
... strategy instead, deeming the
"last expression evaluated is
false" strategy a mere historic annoyance.