Home > Articles > Web Development > Perl

Modules in Perl

  • Print
  • + Share This
  • 💬 Discuss

This chapter is from the book

Make your Perl programs more maintainable and reusable. Learn how to effectively use and document packages and modules.

Over the years, Perl has grown to include many new features. These features make the language richer and more useful—but they also make it more complex for programmers and the Perl maintainers.

Perl 5 partly solved this problem by making the language extensible with modules that range widely in complexity, adding anything from convenience variables to sophisticated database clients and Web development environments. Modules have made it possible for Perl to improve incrementally without changing the language itself.

This chapter begins with a discussion of Perl packages, which allow us to place variables and subroutines in a namespace hierarchy. Once we have discussed packages, we begin to discuss modules—how to use them, how to write them, and how to improve them.

By the end of this chapter, you should understand not just how Perl modules work, but also how you can use them effectively in your programs.

6.1 Packages

Programmers working on large projects often discover that a variable or subroutine name is being used by someone else. Perl and other languages provide packages, or namespaces, which make it easier to avoid such clashes. Packages are analogous to surnames in human society, allowing more than one David or Jennifer to coexist unambiguously.

6.1.1 Packages

Every global variable in Perl exists within a package, with the default package being main. The global variable $x is actually shorthand for $main::x, where main is the package, $x is the variable, and :: separates the package name from the unqualified variable name.

We can similarly refer to variables in other packages. For example, $fruit::mango, @fruit::kiwi, and %fruit::apple are all in the fruit package. As you can see, symbols representing a data type ($, @, or %) precede the package name, not the unqualified variable name. As with variables, packages spring to life when they are first referenced.

Package names may contain ::, allowing us to create what appear to be hierarchies. For instance, $fruit::tropical::kiwi is the variable $kiwi in the package fruit::tropical. However, these names are only significant to programmers; Perl does not notice or enforce hierarchies. As far as Perl is concerned, two unrelated modules can be under the same package hierarchy, and two related modules can be in completely different packages.

At any time in our program, we can set or retrieve the value of any global variable by giving its fully qualified name:

$main::x = 5; 
$blueberry::x = 30; 

print "main::x = $main::x\n"; 
print "blueberry::x = $blueberry::x\n"; 

6.1.2 Lexicals and packages

Lexicals exist outside of a package, in a separate area known as the scratchpad. They have nothing to do with packages or global variables. There is no relationship between $main::var and the lexical $var, except in the mind of a programmer. This program is perfectly legal, but hard for programmers to understand:

#!/usr/bin/perl	 	 
# filename: globals-and-lexicals.pl	 
 	 	 	 
use warnings;	 	 
 	 	 	 
$	main::x = 10;	              # Global	 
my $x = 20;	                      # Lexical	 
 	 	 	 
print "x = '$x'\n";	              # Prints 20 (lexical)
print "main::x = '$main::x'\n";	  # Prints 10 (global)

Once the lexical $x is declared, $main::x must be retrieved with its fully qualified name. Otherwise, Perl will assume that $x refers to the lexical $x, rather than the global $main::x.

6.1.3 use strict

use strict tells the Perl compiler to forbid the use of unqualified global variables, avoiding the ambiguity that we saw in the preceding program. When use strict is active, $x must refer to a lexical explicitly declared with my. If no such lexical has been declared, the program exits with a compilation error:

#!/usr/bin/perl 
# filename: counter.pl 


use strict; 
use warnings; 


# Declare $counter lexical within the 
foreach loop foreach my $counter (0 .. 10) 
{ 
   print "Counter = $counter\n"; 
   $counter++; 
} 

# $counter has disappeared -- fatal compilation error! 
print "Counter at the end is $counter\n"; 

We can fix this program by declaring $counter to be a top-level lexical:

#!/usr/bin/perl 
# filename: new-counter.pl 


use strict; 

use warnings; 


# Declare $counter to be lexical for the entire program 
my $counter; 


# Declare $index to be lexical within the foreach 
foreach my $index (0 .. 10) 
{ 
   print "Counter = $counter\n"; 
   $counter++; 
} 

# Counter still exists 
print "Counter at the end is $counter\n"; 

6.1.4 use vars and our

Experienced Perl programmers include use strict in their programs, because of the number of errors it traps. However, referring to globals by their full names quickly gets tedious.

use vars helps by making an exception to use strict. Variables named in the list passed to use vars can be referred to by their unqualified names, even when use strict is active. For example, the following code tells Perl that $a, $b, and $c in the current package do not need to be fully qualified:

use vars qw($a $b $c); 

In the case of a conflict between my and use vars, the lexical has priority. (After all, you can always set and retrieve the global's value using its fully qualified name, but the lexical has only one name.) The following program demonstrates this:

#!/usr/bin/perl 
# filename: globals-and-lexicals-2.pl 

use strict; 
use warnings; 
use vars qw($x);     # Allows us to write $main::x as $x 


$x = 10;             # Sets global $main::x 
my $x = 20;          # Sets lexical $x 
$x = 30;             # Sets lexical $x, not global $main::x 


print "x = '$x'\n";              # Prints 30 (lexical) 
print "main::x = '$main::x'\n";  # Prints 10 (global) 

As of Perl 5.6, use vars has been deprecated in favor of our. our is similar to my, in that its declarations only last through the current lexical scope. However, our (like use vars) works with global variables, not lexicals. We can rewrite this program as follows using our:

#!/usr/bin/perl 
# filename: globals-and-lexicals-with-our.pl 


use strict; 
use warnings; 
our $x;               # Allows us to write $main::x as $x

$x = 10;              # Sets global $main::
my $x = 20; x         # Sets lexical $x
$x = 30;              # Sets lexical $x, not global $main::x


print "x = '$x'\n";              # Prints 30 (lexical) 
print "main::x = '$main::x'\n";  # Prints 10 (global) 

6.1.5 Switching default packages

To change to a new default package, use the package statement:

package newPackageName; 

A program can change default packages as often as it might like, although doing so can confuse the next person maintaining your code. Remember that package changes the default namespace; it does not change your ability to set or receive any global's value by explicitly naming its package.

There is a subtle difference between use vars and our that comes into play when we change packages. use vars ceases to have effect when you change to a different default package. For example:

package foo;       # Make the default package 'foo' 
use vars qw($x);   # $x is shorthand for $foo::x 

$x = 5;            # Assigns $foo::x 

package bar;       # Make the default package 'bar' 
print "'$x'\n";    # $x refers to $bar::x (undefined) 

package foo;       # Make the default package 'foo' (again) 
print "'$x'\n";    # $x refers to $foo::x 

In this code, use vars tells Perl that $x is shorthand for $foo::x. When we switch into default package bar, $x no longer refers to $foo::x, but $bar::x. Without use strict, Perl allows us to retrieve the value of an undeclared global variable, which has the value undef. When we return to package foo, $x once again refers to $foo::x, and the previous value is once again available.

By contrast, global variables declared with our remain available with their short names even after changing into a different package:

package foo;       # Make the default package 'foo' 
our $x;            # $x is shorthand for $foo::x 

$x = 5;            # Assigns $foo::x 

package bar;       # Make the default package 'bar' 
print "'$x'\n";    # $x still refers to $foo::x 

For $x to refer to $bar::x, we must add an additional our declaration immediately following the second package statement:

package foo;       # Make the default package 'foo' 
our $x;            # $x is shorthand for $foo::x 

$x = 5;            # Assigns $foo::x 

package bar;       # Make the default package 'bar' 

our $x;	           # $x is now shorthand for $bar::x	 
print "'$x'\n";	   # $x now refers to $bar::x	 

6.1.6 Subroutines

When we declare a subroutine, it is placed by default in the current package:

package abc;	 	 
sub foo {return 5;}        # Full name is abc::foo	 	 

This means that when working with more than one package, we may need to qualify subroutine names:

package numbers;           # Default package is "numbers"
sub gimme_five { 5; }      # Define a subroutine	 
 	 	 
package main;              # Default package is now "main"
 	 	 
my $x = gimme_five();	   # Fails to execute main::gimme_five()
print "x = '$x'\n";	       # Prints 5	 

This code exits with a fatal error, with Perl complaining that no subroutine main::gimme five has been defined. We can fix this by invoking the subroutine with its fully qualified name:

Package numbers;                 # Default package is "numbers"
sub gimme_five { 5; }            # Define	a subroutine
 	
package main;                    # Default package is now "main"
 
my $ x = numbers::gimme_five();  # Qualify gimme_five() with a package
print "x	= '$x'\n";           # Prints	5
  • + Share This
  • 🔖 Save To Your Account
Core Perl

This chapter is from the book

Core Perl

Discussions

comments powered by Disqus