Документация
HTML CSS PHP PERL другое

Section 10.7.  Packages as Namespace Separators

 
Previous
Table of Contents
Next

10.7. Packages as Namespace Separators

If the name prefix of the last example didn't have to be spelled out on every use, things would work much better. We can improve the situation by using a package:

package Navigation;

sub turn_toward_heading {
  .. code here ..
}

sub turn_toward_port {
  .. code here ..
}

1;

The package declaration at the beginning of this file tells Perl to virtually insert Navigation:: in front of most names within the file. Thus, the code above practically says:

sub Navigation::turn_toward_heading {
  .. code here ..
}

sub Navigation::turn_toward_port {
  .. code here ..
}

1;

Now when Gilligan uses this file, he simply adds Navigation:: to the subroutines defined in the library and leaves the Navigation:: prefix off for subroutines he defines on his own:

#!/usr/bin/perl

require 'navigation.pm';

sub turn_toward_port {
  Navigation::turn_toward_heading(compute_heading_to_island(  ));
}

sub compute_heading_to_island {
  .. code here ..
}

.. more program here ..

Package names are like variable names: they consist of alphanumerics and underscores but can't begin with a digit. Also, for reasons explained in the perlmodlib documentation, a package name should begin with a capital letter and not overlap an existing CPAN or core module name. Package names can also have multiple names separated by double colons, such as Minnow::Navigation and Minnow::Food::Storage.

Nearly every scalar, array, hash, subroutine, and filehandle name[*] is actually prefixed by the current package, unless the name already contains one or more double-colon markers.

[*] Except lexicals, as we'll show in a moment.

So, in navigation.pm, we can use variables such as:[Section 10.7.  Packages as Namespace Separators]

[Section 10.7.  Packages as Namespace Separators] Trivia note: 21.283 degrees north, 157.842 degrees west is the location of the real-life marina where the opening shot of a famous television series was filmed. Check it out on Google Maps if you don't believe us.

package Navigation;
@homeport = (21.283, -157.842);

sub turn_toward_port {
  .. code ..
}

We can refer to the @homeport variable in the main code with its full package specification:

@destination = @Navigation::homeport;

If every name has a package name inserted in front of it, what about names in the main program? Yes, they are also in a package, called main. It's as if package main; were at the beginning of each file. Thus, to keep Gilligan from having to say Navigation::turn_toward_heading, the navigation.pm file can say:

sub main::turn_toward_heading {
  .. code here ..
}

Now the subroutine is defined in the main package, not the Navigation package. This isn't an optimal solution (we'll show better solutions in Chapter 15 when we talk about Exporter), but at least there's nothing sacred or terribly unique about main compared to any other package.

This is what the modules in Chapter 3 were doing when they imported symbols into our scripts, but we didn't tell you the whole story then. Those modules imported the subroutines and variables into the current package (again, that's main in our scripts, usually). That is, those symbols are only available in that package unless we use the full package specification. We'll get more into how this works later.


Previous
Table of Contents
Next
© 2000- NIV