X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlmod.pod;h=6bec46b0287ed487a4938cb86248dab10af76846;hb=40b568c93a31cb8feae8a14551365dff7e76b624;hp=fc81fdfaaedea8c682f18ab4189415480b704f1c;hpb=c529f79d594c53d3968d464c57ac24a21137dd09;p=p5sagit%2Fp5-mst-13.2.git diff --git a/pod/perlmod.pod b/pod/perlmod.pod index fc81fdf..6bec46b 100644 --- a/pod/perlmod.pod +++ b/pod/perlmod.pod @@ -85,7 +85,7 @@ and L regarding closures. The symbol table for a package happens to be stored in the hash of that name with two colons appended. The main symbol table's name is thus -C<%main::>, or C<%::> for short. Likewise symbol table for the nested +C<%main::>, or C<%::> for short. Likewise the symbol table for the nested package mentioned earlier is named C<%OUTER::INNER::>. The value in each entry of the hash is what you are referring to when you @@ -97,7 +97,7 @@ table lookups at compile time: local $main::{foo} = $main::{bar}; You can use this to print out all the variables in a package, for -instance. The standard but antequated F library and +instance. The standard but antiquated F library and the CPAN module Devel::Symdump make use of this. Assignment to a typeglob performs an aliasing operation, i.e., @@ -115,7 +115,7 @@ Which makes $richard and $dick the same variable, but leaves @richard and @dick as separate arrays. Tricky, eh? This mechanism may be used to pass and return cheap references -into or from subroutines if you won't want to copy the whole +into or from subroutines if you don't want to copy the whole thing. It only works when assigning to dynamic variables, not lexicals. @@ -132,7 +132,7 @@ lexicals. On return, the reference will overwrite the hash slot in the symbol table specified by the *some_hash typeglob. This is a somewhat tricky way of passing around references cheaply -when you won't want to have to remember to dereference variables +when you don't want to have to remember to dereference variables explicitly. Another use of symbol tables is for making "constant" scalars. @@ -141,9 +141,9 @@ Another use of symbol tables is for making "constant" scalars. Now you cannot alter $PI, which is probably a good thing all in all. This isn't the same as a constant subroutine, which is subject to -optimization at compile-time. This isn't. A constant subroutine is one -prototyped to take no arguments and to return a constant expression. -See L for details on these. The C pragma is a +optimization at compile-time. A constant subroutine is one prototyped +to take no arguments and to return a constant expression. See +L for details on these. The C pragma is a convenient shorthand for these. You can say C<*foo{PACKAGE}> and C<*foo{NAME}> to find out what name and @@ -163,7 +163,7 @@ This prints You gave me bar::baz The C<*foo{THING}> notation can also be used to obtain references to the -individual elements of *foo, see L. +individual elements of *foo. See L. Subroutine definitions (and declarations, for that matter) need not necessarily be situated in the package whose symbol table they @@ -212,9 +212,9 @@ This also has implications for the use of the SUPER:: qualifier =head2 Package Constructors and Destructors -Three special subroutines act as package -constructors and destructors. These are the C, C, and -C routines. The C is optional for these routines. +Four special subroutines act as package constructors and destructors. +These are the C, C, C, and C routines. The +C is optional for these routines. A C subroutine is executed as soon as possible, that is, the moment it is completely defined, even before the rest of the containing file @@ -225,29 +225,36 @@ files in time to be visible to the rest of the file. Once a C has run, it is immediately undefined and any code it used is returned to Perl's memory pool. This means you can't ever explicitly call a C. -Similar to C blocks, C blocks are run just before the -Perl runtime begins execution. For example, the code generators -documented in L make use of C blocks to initialize -and resolve pointers to XSUBs. - -An C subroutine is executed as late as possible, that is, when -the interpreter is being exited, even if it is exiting as a result of -a die() function. (But not if it's polymorphing into another program -via C, or being blown out of the water by a signal--you have to -trap that yourself (if you can).) You may have multiple C blocks -within a file--they will execute in reverse order of definition; that is: -last in, first out (LIFO). +An C subroutine is executed as late as possible, that is, after +perl has finished running the program and just before the interpreter +is being exited, even if it is exiting as a result of a die() function. +(But not if it's polymorphing into another program via C, or +being blown out of the water by a signal--you have to trap that yourself +(if you can).) You may have multiple C blocks within a file--they +will execute in reverse order of definition; that is: last in, first +out (LIFO). C blocks are not executed when you run perl with the +C<-c> switch, or if compilation fails. Inside an C subroutine, C<$?> contains the value that the program is going to pass to C. You can modify C<$?> to change the exit value of the program. Beware of changing C<$?> by accident (e.g. by running something via C). +Similar to C blocks, C blocks are run just before the +Perl runtime begins execution, in "first in, first out" (FIFO) order. +For example, the code generators documented in L make use of +C blocks to initialize and resolve pointers to XSUBs. + +Similar to C blocks, C blocks are run just after the +Perl compile phase ends and before the run time begins, in +LIFO order. C blocks are again useful in the Perl compiler +suite to save the compiled state of the program. + When you use the B<-n> and B<-p> switches to Perl, C and -C work just as they do in B, as a degenerate case. As currently -implemented (and subject to change, since its inconvenient at best), -both C and blocks are run when you use the B<-c> switch -for a compile-only syntax check, although your main code is not. +C work just as they do in B, as a degenerate case. +Both C and C blocks are run when you use the B<-c> +switch for a compile-only syntax check, although your main code +is not. =head2 Perl Classes @@ -261,14 +268,14 @@ For more on this, see L and L. =head2 Perl Modules -A module is just a set of related function in a library file a Perl -package with the same name as the file. It is specifically designed -to be reusable by other modules or programs. It may do this by -providing a mechanism for exporting some of its symbols into the +A module is just a set of related functions in a library file, i.e., +a Perl package with the same name as the file. It is specifically +designed to be reusable by other modules or programs. It may do this +by providing a mechanism for exporting some of its symbols into the symbol table of any package using it. Or it may function as a class definition and make its semantics available implicitly through method calls on the class and its objects, without explicitly -exportating anything. Or it can do a little of both. +exporting anything. Or it can do a little of both. For example, to start a traditional, non-OO module called Some::Module, create a file called F and start with this template: @@ -276,6 +283,7 @@ create a file called F and start with this template: package Some::Module; # assumes Some/Module.pm use strict; + use warnings; BEGIN { use Exporter (); @@ -411,19 +419,19 @@ that other module. In that case, it's easy to use Cs instead. Perl packages may be nested inside other package names, so we can have package names containing C<::>. But if we used that package name -directly as a filename it would makes for unwieldy or impossible +directly as a filename it would make for unwieldy or impossible filenames on some systems. Therefore, if a module's name is, say, C, then its definition is actually found in the library file F. Perl modules always have a F<.pm> file, but there may also be dynamically linked executables (often ending in F<.so>) or autoloaded -subroutine definitions (often ending in F<.al> associated with the +subroutine definitions (often ending in F<.al>) associated with the module. If so, these will be entirely transparent to the user of the module. It is the responsibility of the F<.pm> file to load (or arrange to autoload) any additional functionality. For example, although the POSIX module happens to do both dynamic loading and -autoloading, but the user can say just C to get it all. +autoloading, the user can say just C to get it all. =head1 SEE ALSO