Module Design and Implementation

Implementing a named parameter subroutine is easy. Here's one way to do it:

sub check_mail {

   croak("Odd number of parameters to check_mail!") if @_ % 2;

   my %params = @_;

   # ... rest of sub uses %params to access parameters

}

The first line checks to make sure you have an even number of parameters. If you 

omit this test, then the next line will cause a confusing error if a user calls the routine 

with an odd number of parameters.

An alternate way to implement a named parameter style subroutine is to 

require the calling code to pass a reference to a hash as a single parameter. If this 

were done with check_mail(), then the call would look like this:

check_mail({imap_sever => $imap_server,

            username   => $username,

            password   => $password});

As a result, the implementation of the subroutine changes a bit:

sub check_mail {

   croak("Bad call to check_mail   expected a single hash ref!")

      unless @_ == 1 and ref $_[0] eq "HASH";

   my $params = shift;

   # ... rest of sub uses %$params to access parameters

}

Which method you choose is largely a matter of taste.

One of the main benefits of using a named parameter style, aside from the 

ease of use, is in extensibility. For example, let's imagine you need to add a couple 

new optional parameters to the previously documented check_mail() $timeout

and $retries. Since they're optional, they'll have some reasonable default if not 

specified. That makes a call using positional parameters look like the following:

check_mail($imap_server, $username, $password, $mailbox, $timeout, $retries);

The problem is that if you only want to specify one of the optional parameters, 

then you'll need to pad the preceding parameters with undefs. For example, to 

specify a number of retries but leave the other optional parameters alone, an ugly 

call is required:

check_mail($imap_server, $username, $password, undef, undef, $retries);

77

77