1PERLMOD(1) Perl Programmers Reference Guide PERLMOD(1)
2
6 perlmod - Perl modules (packages and symbol tables)
7
9 Is this the document you were after?
10 There are other documents which might contain the information that
11 you're looking for:
12 This doc
14 Perl's packages, namespaces, and some info on classes.
15 perlnewmod
17 Tutorial on making a new module.
18 perlmodstyle
20 Best practices for making a new module.
21 Packages
23 Unlike Perl 4, in which all the variables were dynamic and shared one
24 global name space, causing maintainability problems, Perl 5 provides
25 two mechanisms for protecting code from having its variables stomped on
26 by other code: lexically scoped variables created with "my" or "state"
27 and namespaced global variables, which are exposed via the "vars"
28 pragma, or the "our" keyword. Any global variable is considered to be
29 part of a namespace and can be accessed via a "fully qualified form".
30 Conversely, any lexically scoped variable is considered to be part of
31 that lexical-scope, and does not have a "fully qualified form".
32 In perl namespaces are called "packages" and the "package" declaration
34 tells the compiler which namespace to prefix to "our" variables and
35 unqualified dynamic names. This both protects against accidental
36 stomping and provides an interface for deliberately clobbering global
37 dynamic variables declared and used in other scopes or packages, when
38 that is what you want to do.
39 The scope of the "package" declaration is from the declaration itself
41 through the end of the enclosing block, "eval", or file, whichever
42 comes first (the same scope as the my(), our(), state(), and local()
43 operators, and also the effect of the experimental "reference
44 aliasing," which may change), or until the next "package" declaration.
45 Unqualified dynamic identifiers will be in this namespace, except for
46 those few identifiers that, if unqualified, default to the main package
47 instead of the current one as described below. A "package" statement
48 affects only dynamic global symbols, including subroutine names, and
49 variables you've used local() on, but not lexical variables created
50 with my(), our() or state().
51 Typically, a "package" statement is the first declaration in a file
53 included in a program by one of the "do", "require", or "use"
54 operators. You can switch into a package in more than one place:
55 "package" has no effect beyond specifying which symbol table the
56 compiler will use for dynamic symbols for the rest of that block or
57 until the next "package" statement. You can refer to variables and
58 filehandles in other packages by prefixing the identifier with the
59 package name and a double colon: $Package::Variable. If the package
60 name is null, the "main" package is assumed. That is, $::sail is
61 equivalent to $main::sail.
62 The old package delimiter was a single quote, but double colon is now
64 the preferred delimiter, in part because it's more readable to humans,
65 and in part because it's more readable to emacs macros. It also makes
66 C++ programmers feel like they know what's going on--as opposed to
67 using the single quote as separator, which was there to make Ada
68 programmers feel like they knew what was going on. Because the old-
69 fashioned syntax is still supported for backwards compatibility, if you
70 try to use a string like "This is $owner's house", you'll be accessing
71 $owner::s; that is, the $s variable in package "owner", which is
72 probably not what you meant. Use braces to disambiguate, as in "This
73 is ${owner}'s house".
74 Packages may themselves contain package separators, as in
76 $OUTER::INNER::var. This implies nothing about the order of name
77 lookups, however. There are no relative packages: all symbols are
78 either local to the current package, or must be fully qualified from
79 the outer package name down. For instance, there is nowhere within
80 package "OUTER" that $INNER::var refers to $OUTER::INNER::var. "INNER"
81 refers to a totally separate global package. The custom of treating
82 package names as a hierarchy is very strong, but the language in no way
83 enforces it.
84 Only identifiers starting with letters (or underscore) are stored in a
86 package's symbol table. All other symbols are kept in package "main",
87 including all punctuation variables, like $_. In addition, when
88 unqualified, the identifiers STDIN, STDOUT, STDERR, ARGV, ARGVOUT, ENV,
89 INC, and SIG are forced to be in package "main", even when used for
90 other purposes than their built-in ones. If you have a package called
91 "m", "s", or "y", then you can't use the qualified form of an
92 identifier because it would be instead interpreted as a pattern match,
93 a substitution, or a transliteration.
94 Variables beginning with underscore used to be forced into package
96 main, but we decided it was more useful for package writers to be able
97 to use leading underscore to indicate private variables and method
98 names. However, variables and functions named with a single "_", such
99 as $_ and "sub _", are still forced into the package "main". See also
100 "The Syntax of Variable Names" in perlvar.
101 "eval"ed strings are compiled in the package in which the eval() was
103 compiled. (Assignments to $SIG{}, however, assume the signal handler
104 specified is in the "main" package. Qualify the signal handler name if
105 you wish to have a signal handler in a package.) For an example,
106 examine perldb.pl in the Perl library. It initially switches to the
107 "DB" package so that the debugger doesn't interfere with variables in
108 the program you are trying to debug. At various points, however, it
109 temporarily switches back to the "main" package to evaluate various
110 expressions in the context of the "main" package (or wherever you came
111 from). See perldebug.
112 The special symbol "__PACKAGE__" contains the current package, but
114 cannot (easily) be used to construct variable names. After "my($foo)"
115 has hidden package variable $foo, it can still be accessed, without
116 knowing what package you are in, as "${__PACKAGE__.'::foo'}".
117 See perlsub for other scoping issues related to my() and local(), and
119 perlref regarding closures.
120 Symbol Tables
122 The symbol table for a package happens to be stored in the hash of that
123 name with two colons appended. The main symbol table's name is thus
124 %main::, or %:: for short. Likewise the symbol table for the nested
125 package mentioned earlier is named %OUTER::INNER::.
126 The value in each entry of the hash is what you are referring to when
128 you use the *name typeglob notation.
129 local *main::foo = *main::bar;
131 You can use this to print out all the variables in a package, for
133 instance. The standard but antiquated dumpvar.pl library and the CPAN
134 module Devel::Symdump make use of this.
135 The results of creating new symbol table entries directly or modifying
137 any entries that are not already typeglobs are undefined and subject to
138 change between releases of perl.
139 Assignment to a typeglob performs an aliasing operation, i.e.,
141 *dick = *richard;
143 causes variables, subroutines, formats, and file and directory handles
145 accessible via the identifier "richard" also to be accessible via the
146 identifier "dick". If you want to alias only a particular variable or
147 subroutine, assign a reference instead:
148 *dick = \$richard;
150 Which makes $richard and $dick the same variable, but leaves @richard
152 and @dick as separate arrays. Tricky, eh?
153 There is one subtle difference between the following statements:
155 *foo = *bar;
157 *foo = \$bar;
158 "*foo = *bar" makes the typeglobs themselves synonymous while "*foo =
160 \$bar" makes the SCALAR portions of two distinct typeglobs refer to the
161 same scalar value. This means that the following code:
162 $bar = 1;
164 *foo = \$bar; # Make $foo an alias for $bar
165 {
167 local $bar = 2; # Restrict changes to block
168 print $foo; # Prints '1'!
169 }
170 Would print '1', because $foo holds a reference to the original $bar.
172 The one that was stuffed away by "local()" and which will be restored
173 when the block ends. Because variables are accessed through the
174 typeglob, you can use "*foo = *bar" to create an alias which can be
175 localized. (But be aware that this means you can't have a separate @foo
176 and @bar, etc.)
177 What makes all of this important is that the Exporter module uses glob
179 aliasing as the import/export mechanism. Whether or not you can
180 properly localize a variable that has been exported from a module
181 depends on how it was exported:
182 @EXPORT = qw($FOO); # Usual form, can't be localized
184 @EXPORT = qw(*FOO); # Can be localized
185 You can work around the first case by using the fully qualified name
187 ($Package::FOO) where you need a local value, or by overriding it by
188 saying "*FOO = *Package::FOO" in your script.
189 The "*x = \$y" mechanism may be used to pass and return cheap
191 references into or from subroutines if you don't want to copy the whole
192 thing. It only works when assigning to dynamic variables, not
193 lexicals.
194 %some_hash = (); # can't be my()
196 *some_hash = fn( \%another_hash );
197 sub fn {
198 local *hashsym = shift;
199 # now use %hashsym normally, and you
200 # will affect the caller's %another_hash
201 my %nhash = (); # do what you want
202 return \%nhash;
203 }
204 On return, the reference will overwrite the hash slot in the symbol
206 table specified by the *some_hash typeglob. This is a somewhat tricky
207 way of passing around references cheaply when you don't want to have to
208 remember to dereference variables explicitly.
209 Another use of symbol tables is for making "constant" scalars.
211 *PI = \3.14159265358979;
213 Now you cannot alter $PI, which is probably a good thing all in all.
215 This isn't the same as a constant subroutine, which is subject to
216 optimization at compile-time. A constant subroutine is one prototyped
217 to take no arguments and to return a constant expression. See perlsub
218 for details on these. The "use constant" pragma is a convenient
219 shorthand for these.
220 You can say *foo{PACKAGE} and *foo{NAME} to find out what name and
222 package the *foo symbol table entry comes from. This may be useful in
223 a subroutine that gets passed typeglobs as arguments:
224 sub identify_typeglob {
226 my $glob = shift;
227 print 'You gave me ', *{$glob}{PACKAGE},
228 '::', *{$glob}{NAME}, "\n";
229 }
230 identify_typeglob *foo;
231 identify_typeglob *bar::baz;
232 This prints
234 You gave me main::foo
236 You gave me bar::baz
237 The *foo{THING} notation can also be used to obtain references to the
239 individual elements of *foo. See perlref.
240 Subroutine definitions (and declarations, for that matter) need not
242 necessarily be situated in the package whose symbol table they occupy.
243 You can define a subroutine outside its package by explicitly
244 qualifying the name of the subroutine:
245 package main;
247 sub Some_package::foo { ... } # &foo defined in Some_package
248 This is just a shorthand for a typeglob assignment at compile time:
250 BEGIN { *Some_package::foo = sub { ... } }
252 and is not the same as writing:
254 {
256 package Some_package;
257 sub foo { ... }
258 }
259 In the first two versions, the body of the subroutine is lexically in
261 the main package, not in Some_package. So something like this:
262 package main;
264 $Some_package::name = "fred";
266 $main::name = "barney";
267 sub Some_package::foo {
269 print "in ", __PACKAGE__, ": \$name is '$name'\n";
270 }
271 Some_package::foo();
273 prints:
275 in main: $name is 'barney'
277 rather than:
279 in Some_package: $name is 'fred'
281 This also has implications for the use of the SUPER:: qualifier (see
283 perlobj).
284 BEGIN, UNITCHECK, CHECK, INIT and END
286 Five specially named code blocks are executed at the beginning and at
287 the end of a running Perl program. These are the "BEGIN", "UNITCHECK",
288 "CHECK", "INIT", and "END" blocks.
289 These code blocks can be prefixed with "sub" to give the appearance of
291 a subroutine (although this is not considered good style). One should
292 note that these code blocks don't really exist as named subroutines
293 (despite their appearance). The thing that gives this away is the fact
294 that you can have more than one of these code blocks in a program, and
295 they will get all executed at the appropriate moment. So you can't
296 execute any of these code blocks by name.
297 A "BEGIN" code block is executed as soon as possible, that is, the
299 moment it is completely defined, even before the rest of the containing
300 file (or string) is parsed. You may have multiple "BEGIN" blocks
301 within a file (or eval'ed string); they will execute in order of
302 definition. Because a "BEGIN" code block executes immediately, it can
303 pull in definitions of subroutines and such from other files in time to
304 be visible to the rest of the compile and run time. Once a "BEGIN" has
305 run, it is immediately undefined and any code it used is returned to
306 Perl's memory pool.
307 An "END" code block is executed as late as possible, that is, after
309 perl has finished running the program and just before the interpreter
310 is being exited, even if it is exiting as a result of a die() function.
311 (But not if it's morphing into another program via "exec", or being
312 blown out of the water by a signal--you have to trap that yourself (if
313 you can).) You may have multiple "END" blocks within a file--they will
314 execute in reverse order of definition; that is: last in, first out
315 (LIFO). "END" blocks are not executed when you run perl with the "-c"
316 switch, or if compilation fails.
317 Note that "END" code blocks are not executed at the end of a string
319 "eval()": if any "END" code blocks are created in a string "eval()",
320 they will be executed just as any other "END" code block of that
321 package in LIFO order just before the interpreter is being exited.
322 Inside an "END" code block, $? contains the value that the program is
324 going to pass to "exit()". You can modify $? to change the exit value
325 of the program. Beware of changing $? by accident (e.g. by running
326 something via "system").
327 Inside of a "END" block, the value of "${^GLOBAL_PHASE}" will be "END".
329 "UNITCHECK", "CHECK" and "INIT" code blocks are useful to catch the
331 transition between the compilation phase and the execution phase of the
332 main program.
333 "UNITCHECK" blocks are run just after the unit which defined them has
335 been compiled. The main program file and each module it loads are
336 compilation units, as are string "eval"s, run-time code compiled using
337 the "(?{ })" construct in a regex, calls to "do FILE", "require FILE",
338 and code after the "-e" switch on the command line.
339 "BEGIN" and "UNITCHECK" blocks are not directly related to the phase of
341 the interpreter. They can be created and executed during any phase.
342 "CHECK" code blocks are run just after the initial Perl compile phase
344 ends and before the run time begins, in LIFO order. "CHECK" code
345 blocks are used in the Perl compiler suite to save the compiled state
346 of the program.
347 Inside of a "CHECK" block, the value of "${^GLOBAL_PHASE}" will be
349 "CHECK".
350 "INIT" blocks are run just before the Perl runtime begins execution, in
352 "first in, first out" (FIFO) order.
353 Inside of an "INIT" block, the value of "${^GLOBAL_PHASE}" will be
355 "INIT".
356 The "CHECK" and "INIT" blocks in code compiled by "require", string
358 "do", or string "eval" will not be executed if they occur after the end
359 of the main compilation phase; that can be a problem in mod_perl and
360 other persistent environments which use those functions to load code at
361 runtime.
362 When you use the -n and -p switches to Perl, "BEGIN" and "END" work
364 just as they do in awk, as a degenerate case. Both "BEGIN" and "CHECK"
365 blocks are run when you use the -c switch for a compile-only syntax
366 check, although your main code is not.
367 The begincheck program makes it all clear, eventually:
369 #!/usr/bin/perl
371 # begincheck
373 print "10. Ordinary code runs at runtime.\n";
375 END { print "16. So this is the end of the tale.\n" }
377 INIT { print " 7. INIT blocks run FIFO just before runtime.\n" }
378 UNITCHECK {
379 print " 4. And therefore before any CHECK blocks.\n"
380 }
381 CHECK { print " 6. So this is the sixth line.\n" }
382 print "11. It runs in order, of course.\n";
384 BEGIN { print " 1. BEGIN blocks run FIFO during compilation.\n" }
386 END { print "15. Read perlmod for the rest of the story.\n" }
387 CHECK { print " 5. CHECK blocks run LIFO after all compilation.\n" }
388 INIT { print " 8. Run this again, using Perl's -c switch.\n" }
389 print "12. This is anti-obfuscated code.\n";
391 END { print "14. END blocks run LIFO at quitting time.\n" }
393 BEGIN { print " 2. So this line comes out second.\n" }
394 UNITCHECK {
395 print " 3. UNITCHECK blocks run LIFO after each file is compiled.\n"
396 }
397 INIT { print " 9. You'll see the difference right away.\n" }
398 print "13. It only _looks_ like it should be confusing.\n";
400 __END__
402 Perl Classes
404 There is no special class syntax in Perl, but a package may act as a
405 class if it provides subroutines to act as methods. Such a package may
406 also derive some of its methods from another class (package) by listing
407 the other package name(s) in its global @ISA array (which must be a
408 package global, not a lexical).
409 For more on this, see perlootut and perlobj.
411 Perl Modules
413 A module is just a set of related functions in a library file, i.e., a
414 Perl package with the same name as the file. It is specifically
415 designed to be reusable by other modules or programs. It may do this
416 by providing a mechanism for exporting some of its symbols into the
417 symbol table of any package using it, or it may function as a class
418 definition and make its semantics available implicitly through method
419 calls on the class and its objects, without explicitly exporting
420 anything. Or it can do a little of both.
421 For example, to start a traditional, non-OO module called Some::Module,
423 create a file called Some/Module.pm and start with this template:
424 package Some::Module; # assumes Some/Module.pm
426 use strict;
428 use warnings;
429 BEGIN {
431 require Exporter;
432 # set the version for version checking
434 our $VERSION = 1.00;
435 # Inherit from Exporter to export functions and variables
437 our @ISA = qw(Exporter);
438 # Functions and variables which are exported by default
440 our @EXPORT = qw(func1 func2);
441 # Functions and variables which can be optionally exported
443 our @EXPORT_OK = qw($Var1 %Hashit func3);
444 }
445 # exported package globals go here
447 our $Var1 = '';
448 our %Hashit = ();
449 # non-exported package globals go here
451 # (they are still accessible as $Some::Module::stuff)
452 our @more = ();
453 our $stuff = '';
454 # file-private lexicals go here, before any functions which use them
456 my $priv_var = '';
457 my %secret_hash = ();
458 # here's a file-private function as a closure,
460 # callable as $priv_func->();
461 my $priv_func = sub {
462 ...
463 };
464 # make all your functions, whether exported or not;
466 # remember to put something interesting in the {} stubs
467 sub func1 { ... }
468 sub func2 { ... }
469 # this one isn't exported, but could be called directly
471 # as Some::Module::func3()
472 sub func3 { ... }
473 END { ... } # module clean-up code here (global destructor)
475 1; # don't forget to return a true value from the file
477 Then go on to declare and use your variables in functions without any
479 qualifications. See Exporter and the perlmodlib for details on
480 mechanics and style issues in module creation.
481 Perl modules are included into your program by saying
483 use Module;
485 or
487 use Module LIST;
489 This is exactly equivalent to
491 BEGIN { require 'Module.pm'; 'Module'->import; }
493 or
495 BEGIN { require 'Module.pm'; 'Module'->import( LIST ); }
497 As a special case
499 use Module ();
501 is exactly equivalent to
503 BEGIN { require 'Module.pm'; }
505 All Perl module files have the extension .pm. The "use" operator
507 assumes this so you don't have to spell out "Module.pm" in quotes.
508 This also helps to differentiate new modules from old .pl and .ph
509 files. Module names are also capitalized unless they're functioning as
510 pragmas; pragmas are in effect compiler directives, and are sometimes
511 called "pragmatic modules" (or even "pragmata" if you're a classicist).
512 The two statements:
514 require SomeModule;
516 require "SomeModule.pm";
517 differ from each other in two ways. In the first case, any double
519 colons in the module name, such as "Some::Module", are translated into
520 your system's directory separator, usually "/". The second case does
521 not, and would have to be specified literally. The other difference is
522 that seeing the first "require" clues in the compiler that uses of
523 indirect object notation involving "SomeModule", as in "$ob = purge
524 SomeModule", are method calls, not function calls. (Yes, this really
525 can make a difference.)
526 Because the "use" statement implies a "BEGIN" block, the importing of
528 semantics happens as soon as the "use" statement is compiled, before
529 the rest of the file is compiled. This is how it is able to function
530 as a pragma mechanism, and also how modules are able to declare
531 subroutines that are then visible as list or unary operators for the
532 rest of the current file. This will not work if you use "require"
533 instead of "use". With "require" you can get into this problem:
534 require Cwd; # make Cwd:: accessible
536 $here = Cwd::getcwd();
537 use Cwd; # import names from Cwd::
539 $here = getcwd();
540 require Cwd; # make Cwd:: accessible
542 $here = getcwd(); # oops! no main::getcwd()
543 In general, "use Module ()" is recommended over "require Module",
545 because it determines module availability at compile time, not in the
546 middle of your program's execution. An exception would be if two
547 modules each tried to "use" each other, and each also called a function
548 from that other module. In that case, it's easy to use "require"
549 instead.
550 Perl packages may be nested inside other package names, so we can have
552 package names containing "::". But if we used that package name
553 directly as a filename it would make for unwieldy or impossible
554 filenames on some systems. Therefore, if a module's name is, say,
555 "Text::Soundex", then its definition is actually found in the library
556 file Text/Soundex.pm.
557 Perl modules always have a .pm file, but there may also be dynamically
559 linked executables (often ending in .so) or autoloaded subroutine
560 definitions (often ending in .al) associated with the module. If so,
561 these will be entirely transparent to the user of the module. It is
562 the responsibility of the .pm file to load (or arrange to autoload) any
563 additional functionality. For example, although the POSIX module
564 happens to do both dynamic loading and autoloading, the user can say
565 just "use POSIX" to get it all.
566 Making your module threadsafe
568 Perl supports a type of threads called interpreter threads (ithreads).
569 These threads can be used explicitly and implicitly.
570 Ithreads work by cloning the data tree so that no data is shared
572 between different threads. These threads can be used by using the
573 "threads" module or by doing fork() on win32 (fake fork() support).
574 When a thread is cloned all Perl data is cloned, however non-Perl data
575 cannot be cloned automatically. Perl after 5.8.0 has support for the
576 "CLONE" special subroutine. In "CLONE" you can do whatever you need to
577 do, like for example handle the cloning of non-Perl data, if necessary.
578 "CLONE" will be called once as a class method for every package that
579 has it defined (or inherits it). It will be called in the context of
580 the new thread, so all modifications are made in the new area.
581 Currently CLONE is called with no parameters other than the invocant
582 package name, but code should not assume that this will remain
583 unchanged, as it is likely that in future extra parameters will be
584 passed in to give more information about the state of cloning.
585 If you want to CLONE all objects you will need to keep track of them
587 per package. This is simply done using a hash and
588 Scalar::Util::weaken().
589 Perl after 5.8.7 has support for the "CLONE_SKIP" special subroutine.
591 Like "CLONE", "CLONE_SKIP" is called once per package; however, it is
592 called just before cloning starts, and in the context of the parent
593 thread. If it returns a true value, then no objects of that class will
594 be cloned; or rather, they will be copied as unblessed, undef values.
595 For example: if in the parent there are two references to a single
596 blessed hash, then in the child there will be two references to a
597 single undefined scalar value instead. This provides a simple
598 mechanism for making a module threadsafe; just add "sub CLONE_SKIP { 1
599 }" at the top of the class, and "DESTROY()" will now only be called
600 once per object. Of course, if the child thread needs to make use of
601 the objects, then a more sophisticated approach is needed.
602 Like "CLONE", "CLONE_SKIP" is currently called with no parameters other
604 than the invocant package name, although that may change. Similarly, to
605 allow for future expansion, the return value should be a single 0 or 1
606 value.
607
609 See perlmodlib for general style issues related to building Perl
610 modules and classes, as well as descriptions of the standard library
611 and CPAN, Exporter for how Perl's standard import/export mechanism
612 works, perlootut and perlobj for in-depth information on creating
613 classes, perlobj for a hard-core reference document on objects, perlsub
614 for an explanation of functions and scoping, and perlxstut and perlguts
615 for more information on writing extension modules.
616perl v5.26.3 2018-03-23 PERLMOD(1)