Many people consider the CPAN (cpan) to be Perl 5's most compelling feature. The CPAN is, at its core, a system for finding and installing modules. A module is a package contained in its own file and loadable with use or require. A module must be valid Perl 5 code. It must end with an expression which evaluates to a true value so that the Perl 5 parser knows it has loaded and compiled the module successfully. There are no other requirements, only strong conventions.
When you load a module, Perl splits the package name on double-colons (::) and turns the components of the package name into a file path. In practice, use StrangeMonkey; causes Perl to search for a file named StrangeMonkey.pm in every directory in @INC, in order, until it finds one or exhausts the list.
Similarly, use StrangeMonkey::Persistence; causes Perl to search for a file named Persistence.pm in every directory named StrangeMonkey/ present in every directory in @INC, and so on. use StrangeMonkey::UI::Mobile; causes Perl to search for a relative file path of StrangeMonkey/UI/Mobile.pm in every directory in @INC.
The resulting file may or may not contain a package declaration matching its filename--there is no such technical requirement--but maintenance concerns recommend that convention.
When you load a module with use, Perl loads it from disk, then calls its import() method, passing any arguments you provided. By convention, a module's import() method takes a list of names and exports functions and other symbols into the calling namespace. This is merely convention; a module may decline to provide an import(), or its import() may perform other behaviors. Pragmas (pragmas) such as strict use arguments to change the behavior of the calling lexical scope instead of exporting symbols:
The no builtin calls a module's unimport() method, if it exists, passing any arguments. This is most common with pragmas which introduce modify behavior through import():
Both use and no take effect during compilation, such that:
... is the same as:
Similarly:
... is the same as:
... including the require of the module.
You may call import() and unimport() directly, though outside of a BEGIN block it makes little sense to do so; after compilation has completed, the effects of import() or unimport() may have little effect.
Perl 5's use and require are case-sensitive, though while Perl knows the difference between strict and Strict, your combination of operating system and file system may not. If you were to write use Strict;, Perl would not find strict.pm on a case-sensitive filesystem. With a case-insensitive filesystem, Perl would happily load Strict.pm, but nothing would happen when it tried to call Strict->import(). (strict.pm declares a package named strict.)
Portable programs are strict about case even if they don't have to be.
A module can make certain global symbols available to other packages through a process known as exporting--a process initiated by calling import() whether implicitly or directly.
The core module Exporter provides a standard mechanism to export symbols from a module. Exporter relies on the presence of package global variables--@EXPORT_OK and @EXPORT in particular--which contain a list of symbols to export when requested.
Consider a StrangeMonkey::Utilities module which provides several standalone functions usable throughout the system:
Any other code now can use this module and, optionally, import any or all of the three exported functions. You may also export variables:
Export symbols by default by listing them in @EXPORT instead of @EXPORT_OK:
... so that any use StrangeMonkey::Utilities; will import both functions. Be aware that specifying symbols to import will not import default symbols; you only get what you request. To load a module without importing any symbols, providing an explicit empty list:
Regardless of any import lists, you can always call functions in another package with their fully-qualified names:
Perl 5 does not require you to use modules, nor packages, nor namespaces. You may put all of your code in a single .pl file, or in multiple .pl files you require as necessary. You have the flexibility to manage your code in the most appropriate way, given your development style, the formality and risk and reward of the project, your experience, and your comfort with Perl 5 deployment.
Even so, a project with more than a couple of hundred lines of code receives multiple benefits from module organization:
Modules help to enforce a logical separation between distinct entities in the system.
Modules provide an API boundary, whether procedural or OO.
Modules suggest a natural organization of source code.
The Perl 5 ecosystem has many tools devoted to creating, maintaining, organizing, and deploying modules and distributions.
Modules provide a mechanism of code reuse.
Even if you do not use an object-oriented approach, modeling every distinct entity or responsibility in your system with its own module keeps related code together and separate code separate.
Hey! The above document had some coding errors, which are explained below:
- Around line 3:
-
A non-empty Z<>
- Around line 49:
-
A non-empty Z<>
- Around line 167:
-
A non-empty Z<>