Content deleted Content added
m Disambiguating links to Object-orientation (link changed to Object-oriented programming) using DisamAssist. |
|||
| (8 intermediate revisions by 6 users not shown) | |||
Line 1:
[[File:Perl_module.png|thumb|Diagram of the mechanism of using perl modules.]]
A '''Perl module''' is a discrete component of [[software]] for the [[Perl]] [[programming language]]. Technically, it is a particular set of [[Convention (norm)|conventions]] for using [[#Perl packages and namespaces|Perl's package mechanism]] that has become universally adopted.{{discuss|Packages and modules}}
A module defines its [[source code]] to be in a ''package'' (much like a [[Java package]]), the Perl mechanism for defining [[namespaces]], e.g. ''CGI'' or ''Net::FTP'' or ''XML::Parser''; the file structure mirrors the [[namespace]] structure (e.g. the
A collection of modules, with accompanying [[Software documentation|documentation]], [[Build automation|build scripts]], and usually a [[test suite]],
Perl is a language allowing many different styles of programming.
It is common for Perl modules to have embedded documentation in Perl's [[Plain Old Documentation]] format. POD imposes little structure on the author. It is flexible enough to be used to write articles, web pages and even entire books such as [https://web.archive.org/web/20070316052422/http://www.oreilly.com/catalog/pperl3/colophon.html Programming Perl]. Contrast with [[javadoc]] which is specialized to documenting [[Java (programming language)|Java]] classes. By convention, module documentation typically follows the structure of a [[Manual page (Unix)|Unix man page]].
Line 14 ⟶ 15:
What follows are examples of "[[Hello world program|Hello, World]]" implemented in different styles of modules. It must be understood that a module is not necessary in Perl; functions and code can be defined and used anywhere. This is just for example purposes. Contrast with [[Java (programming language)|Java]] where a class is always necessary. A real "Hello, World" function would be written like so:
<
sub hello { "Hello, world!\n" }
print hello();
</syntaxhighlight>
or simply printed in one line:
<
print "Hello, world!\n";
</syntaxhighlight>
===Procedural example===
Line 28 ⟶ 29:
====''hello_world.pl''====
<
#!/usr/bin/env perl
# Loads the module and imports any functions into our namespace
# (defaults to "main") exported by the module. Hello::World exports
Line 37 ⟶ 38:
print hello(); # prints "Hello, world!\n"
print hello("Milky Way"); # prints "Hello, Milky Way!\n"
</syntaxhighlight>
====''Hello/World.pm''====
<
# "package" is the namespace where the module's functionality/data resides.
# It dictates the name of the file if you want it to be "use"d.
Line 130 ⟶ 131:
# this is rarely used and it would instead die() (exit with an error).
1;
</syntaxhighlight>
----
Since Hello/World.pm is not in your @INC path, you must specify . on the command line to run the above example:
perl -I. hello_world.pl
===Object-oriented example===
Line 139 ⟶ 144:
====''hello_world.pl''====
<
#!/usr/bin/env perl
use Hello::World;
Line 151 ⟶ 156:
$greeting->print; # prints "Hello, Pittsburgh!\n"
$hello->print; # still prints "Hello, Milky Way!\n"
</syntaxhighlight>
====''Hello/World.pm''====
<
# In Perl there is no special 'class' definition. A namespace is a class.
package Hello::World;
Line 195 ⟶ 200:
sub new {
}
Line 216 ⟶ 221:
sub target {
my $self = shift;
if ( @_ ) {
my $target = shift;
$self->{target} = $target;
}
return $self->{target};
}
Line 235 ⟶ 240:
sub to_string {
}
Line 249 ⟶ 254:
sub print {
}
Line 260 ⟶ 265:
1;
</syntaxhighlight>
----
==Perl packages and namespaces==
A running Perl program has a built-in [[namespace]] called "<code>main</code>", which is the default name. For example, a subroutine called <code>Sub1</code> can be called as <code>Sub1()</code> or <code>main::Sub1()</code>. With a variable the appropriate [[Sigil (computer programming)|sigil]] is placed in front of the namespace; so a scalar variable called <code>$var1</code> can also be referred to as <code>$main::var1</code>, or even <code>$::var1</code>. Other namespaces can be created at any time.
<
package Namespace1;
$var1 = 1; # created in namespace Namespace1, which is also created if not pre-existing
our $var2 = 2; # also created in that namespace; our required if use strict is applied
my $var3 = 3; # lexically-scoped my-declared - NOT in any namespace, not even main
</syntaxhighlight>
<
$Namespace2::var1 = 10; # created in namespace Namespace2, also created if not pre-existing
our $Namespace2::var2 = 20; # also created in that namespace
my $Namespace2::var3 = 30;#compilation error:my-declared variables CAN'T belong to a package
</syntaxhighlight>
Package declarations apply package scope till the next package declaration or the end of the block in which the declaration is made.
<
our $mainVar = 'a';
package Sp1;
Line 292 ⟶ 297:
$mainVar = 'b';
{
{
} # note package Sp1 applies by default
# main applies again by default; all package variables still accessible as long as qualified
print "$mainVar\t$Sp1::sp1aVar$Sp2::sp2bVar\n";
</syntaxhighlight>
===Packages and modules===
Conventionally, namespaces are associated with modules; in practice, there is usually one namespace per module and vice versa, but that's not mandated by the language. For example, the 'standard' module CGI.pm has the following declaration at its top:
<
package CGI;
</syntaxhighlight>
This module, and its functionality, would commonly be invoked as follows:
<
use CGI (':standard'); # imports many functions, including b()
...
print b('Hello, world'); # outputs <b>Hello, world</b>
</syntaxhighlight>
A 'missing' subroutine ''could'' be added from the using program's namespace.
<
sub CGI::bi { # define target namespace (CGI) and sub name (bi)
}
</syntaxhighlight>
and invoked as below:
<
print CGI::bi('Hello, world'); # outputs <b><i>Hello, world</i></b>
</syntaxhighlight>
However, though technically feasible, that would be dubious programming practice. You might just as well define the sub in the calling namespace, and call it from that namespace.
| |||