ЭЛЕКТРОННАЯ БИБЛИОТЕКА КОАПП |
Сборники Художественной, Технической, Справочной, Английской, Нормативной, Исторической, и др. литературы. |
5.2 ModulesA module is just a reusable package that is defined in a library file whose name is the same as the name of the package (with a .pm on the end). A module may provide a mechanism for exporting some of its symbols into the symbol table of any other package using it. Or it may function as a class definition and make its operations available implicitly through method calls on the class and its objects, without explicitly exporting any symbols. Or it can do a little of both. Most exporter modules rely on the customary exportation semantics supplied by the Exporter module. For example, to create an exporting module called Fred, create a file called Fred.pm and put this at the start of it: package Fred; require Exporter; @ISA = qw(Exporter); @EXPORT = qw(func1 func2); @EXPORT_OK = qw($sally @listabob %harry func3); Then go on to declare and use your variables and functions without any qualifications. See the Exporter module documentation in Chapter 7 for further information on the mechanics and style issues in module creation. Perl modules are included in your program by saying: use Module; or: use Module This preloads Module at compile time, and then imports from it the
symbols you've requested, either implicitly or explicitly. If you do
not supply a list of symbols in a BEGIN { require "Module.pm"; Module->import(); } or: BEGIN {
require "Module.pm";
Module->import( (We said that the first example above
defaults to using the module's Sometimes you might not wish to import anything from a module that exports things by default. As a special case, you can say: use Module (); which is exactly equivalent to BEGIN { require "Module.pm"; } Note that any initialization code in the Module is still run, as it would be for an ordinary require. It's only the import that is suppressed. If you really don't care whether the module is pulled in at compile-time or run-time, you can just say: require Module; This is slightly preferred over All Perl module files have the extension .pm. Both use and
require will assume this (as well as the quotes) so that you don't
have to spell out Because the use declaration (in any form) implies a require Cwd; # make Cwd:: accessible with qualification $here = Cwd::getcwd(); use Cwd; # import names from Cwd:: -- no qualification necessary $here = getcwd(); In general, use is recommended over require because you get your error messages sooner. But require is useful for pulling in modules lazily at run-time. Perl packages may be nested inside other packages, so we can have
package names containing " Perl modules always load a .pm file, but there may also be dynamically linked executables or autoloaded subroutine definitions associated with the module. If so, these will be entirely transparent to the user of the module. It is the responsibility of the .pm file to load (or arrange to autoload) any additional functionality. The POSIX module happens to do both dynamic loading and autoloading, but the user can just say use POSIX; to get it all. 5.2.1 Access to ModulesPerl does not patrol private/public borders within its modules - unlike languages such as C++, Ada, and Modula-17, Perl isn't infatuated with enforced privacy. As we mentioned at the beginning of the chapter, a Perl module would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun. The module and its user have a contract, part of which is common law and part of which is written. Part of the common law contract is that a module doesn't pollute any namespace it wasn't asked to pollute. The written contract for the module (that is, the documentation) may make other provisions. But then, having read the written contract, you presumably know that when you say: use RedefineTheWorld; you're redefining the world, and you're willing to take the consequences. The next section talks about one way to redefine parts of the world. 5.2.2 Overriding Built-in FunctionsMany built-in functions may be overridden, although (like knocking holes in your walls) you should only try this occasionally and for good reason. Typically, this might be done by a package attempting to emulate missing built-in functionality on a non-UNIX system. (Do not confuse overriding with overloading, which adds additional object-oriented meanings to built-in operators, but doesn't override much of anything. See the discussion of the overload module in Chapter 7 for more on that.) Overriding may be done only by importing the name from a
module - ordinary predeclaration isn't good enough. To be perfectly
forthcoming, it's the assignment of a code reference to a typeglob that
triggers the override, as in use subs qw(chdir chroot chmod chown); chdir $somewhere; sub chdir { ... } Library modules should not in general export built-in names like
open
or chdir as part of their default
use Module 'open'; and it would import the open override, but if they said use Module; they would get the default imports without the overrides. The original versions of the built-in functions are always accessible
via the |