X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlmodlib.pod;h=164cb643f736673dbefc2ce9af1666a88ef1e5f8;hb=c9d5ac959cdfa7a668b3bfbbc2b56923c316ef43;hp=f4331c332493a984356ed6adcce51f5ac50aa8c5;hpb=6cecdcac8975bfe2a12272798634919e91b189db;p=p5sagit%2Fp5-mst-13.2.git

diff --git a/pod/perlmodlib.pod b/pod/perlmodlib.pod
index f4331c3..164cb64 100644
--- a/pod/perlmodlib.pod
+++ b/pod/perlmodlib.pod
@@ -802,23 +802,28 @@ By-name interface to Perl's built-in getpw*() functions
 
 To find out I<all> modules installed on your system, including
 those without documentation or outside the standard release, 
-jus tdo this:
+just do this:
 
     % find `perl -e 'print "@INC"'` -name '*.pm' -print
 
-They should all have their own documentation installed and accessible
-via your system man(1) command.  If you do not have a B<find>
+To get a log of all module distributions which have been installed
+since perl was installed, just do:
+
+    % perldoc perllocal
+
+Modules should all have their own documentation installed and accessible
+via your system man(1) command, or via the C<perldoc> program.  If you do
+not have a B<find>
 program, you can use the Perl B<find2perl> program instead, which
 generates Perl code as output you can run through perl.  If you
 have a B<man> program but it doesn't find your modules, you'll have
-to fix your manpath.  See L<perl> for details.  If you have no
-system B<man> command, you might try the B<perldoc> program.
+to fix your manpath.  See L<perl> for details.
 
 =head2 Extension Modules
 
 Extension modules are written in C (or a mix of Perl and C).  They
 are usually dynamically loaded into Perl if and when you need them,
-but may also be be linked in statically.  Supported extension modules
+but may also be linked in statically.  Supported extension modules
 include Socket, Fcntl, and POSIX.
 
 Many popular C extension modules do not come bundled (at least, not
@@ -1120,7 +1125,9 @@ scheme as the original author.
 
 =item Try to design the new module to be easy to extend and reuse.
 
-Always use B<-w>.  
+Try to C<use warnings;> (or C<use warnings qw(...);>).
+Remember that you can add C<no warnings qw(...);> to individual blocks
+of code that need less warnings.  
 
 Use blessed references.  Use the two argument form of bless to bless
 into the class name given as the first parameter of the constructor,
@@ -1150,8 +1157,8 @@ Generally you can delete the C<eq 'FOO'> part with no harm at all.
 Let the objects look after themselves! Generally, avoid hard-wired
 class names as far as possible.
 
-Avoid C<$r-E<gt>Class::func()> where using C<@ISA=qw(... Class ...)> and
-C<$r-E<gt>func()> would work (see L<perlbot> for more details).
+Avoid C<< $r->Class::func() >> where using C<@ISA=qw(... Class ...)> and
+C<< $r->func() >> would work (see L<perlbot> for more details).
 
 Use autosplit so little used or newly added functions won't be a
 burden to programs that don't use them. Add test functions to
@@ -1208,7 +1215,7 @@ or nature of a variable. For example:
  $no_caps_here    function scope my() or local() variables
 
 Function and method names seem to work best as all lowercase.
-e.g., C<$obj-E<gt>as_string()>.
+e.g., C<< $obj->as_string() >>.
 
 You can use a leading underscore to indicate that a variable or
 function should not be used outside the package that defined it.
@@ -1224,7 +1231,7 @@ export try to use @EXPORT_OK in preference to @EXPORT and avoid
 short or common names to reduce the risk of name clashes.
 
 Generally anything not exported is still accessible from outside the
-module using the ModuleName::item_name (or C<$blessed_ref-E<gt>method>)
+module using the ModuleName::item_name (or C<< $blessed_ref->method >>)
 syntax.  By convention you can use a leading underscore on names to
 indicate informally that they are 'internal' and not for public use.