X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlmod.pod;h=6bec46b0287ed487a4938cb86248dab10af76846;hb=40b568c93a31cb8feae8a14551365dff7e76b624;hp=351ba73c5a6e84d806e600721d89efaca0e917db;hpb=7d9816167178f34fbf6a461f535912586fae6223;p=p5sagit%2Fp5-mst-13.2.git diff --git a/pod/perlmod.pod b/pod/perlmod.pod index 351ba73..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 @@ -213,7 +213,7 @@ This also has implications for the use of the SUPER:: qualifier =head2 Package Constructors and Destructors Four special subroutines act as package constructors and destructors. -These are the C, C, C, and C routines. The +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 @@ -233,7 +233,7 @@ 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. +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 @@ -245,16 +245,16 @@ 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 +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 +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 @@ -268,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: @@ -283,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 (); @@ -418,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