Front page | perl.perl5.porters |
Postings from April 2003
[perl #22011] [PATCH] pod/perlmod.pod (v5.8.0)
From: Chris Pepper
April 22, 2003 07:46
[perl #22011] [PATCH] pod/perlmod.pod (v5.8.0)
Message ID: email@example.com
# New Ticket Created by Chris Pepper
# Please include the string: [perl #22011]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22011 >
Reading the docs, I found a few typos and language problems.
Suggested patch follows. If I should submit this differently, please
--- perlmod.pod Sun Jun 9 12:50:22 2002
+++ perlmod.pod.fixed Mon Apr 21 20:05:08 2003
@@ -33,7 +33,7 @@
in part because it's more readable to B<emacs> macros. It also makes C++
programmers feel like they know what's going on--as opposed to using the
single quote as separator, which was there to make Ada programmers feel
-like they knew what's going on. Because the old-fashioned syntax is still
+like they knew what was going on. Because the old-fashioned syntax is still
supported for backwards compatibility, if you try to use a string like
C<"This is $owner's house">, you'll be accessing C<$owner::s>; that is,
the $s variable in package C<owner>, which is probably not what you meant.
@@ -45,7 +45,7 @@
are either local to the current package, or must be fully qualified
from the outer package name down. For instance, there is nowhere
within package C<OUTER> that C<$INNER::var> refers to
-C<$OUTER::INNER::var>. It would treat package C<INNER> as a totally
+C<$OUTER::INNER::var>. C<INNER> refers to a totally
separate global package.
Only identifiers starting with letters (or underscore) are stored
@@ -53,7 +53,7 @@
C<main>, including all punctuation variables, like $_. In addition,
when unqualified, the identifiers STDIN, STDOUT, STDERR, ARGV,
ARGVOUT, ENV, INC, and SIG are forced to be in package C<main>,
-even when used for other purposes than their built-in one. If you
+even when used for other purposes than their built-in ones. If you
have a package called C<m>, C<s>, or C<y>, then you can't use the
qualified form of an identifier because it would be instead interpreted
as a pattern match, a substitution, or a transliteration.
@@ -76,7 +76,7 @@
from). See L<perldebug>.
The special symbol C<__PACKAGE__> contains the current package, but cannot
-(easily) be used to construct variables.
+(easily) be used to construct variable names.
See L<perlsub> for other scoping issues related to my() and local(),
and L<perlref> regarding closures.
@@ -274,7 +274,7 @@
being blown out of the water by a signal--you have to trap that yourself
(if you can).) You may have multiple C<END> blocks within a file--they
will execute in reverse order of definition; that is: last in, first
-out (LIFO). C<END> blocks are not executed when you run perl with the
+out (LIFO). C<END> blocks are not executed when you run Perl with the
C<-c> switch, or if compilation fails.
Inside an C<END> subroutine, C<$?> contains the value that the program is
@@ -314,7 +314,7 @@
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
+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
exporting anything. Or it can do a little of both.
@@ -461,7 +461,7 @@
because it determines module availability at compile time, not in the
middle of your program's execution. An exception would be if two modules
each tried to C<use> each other, and each also called a function from
-that other module. In that case, it's easy to use C<require>s instead.
+that other module. In that case, it's easy to use C<require> 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
@@ -481,11 +481,12 @@
=head2 Making your module threadsafe
-Perl has since 5.6.0 support for a new type of threads called
-interpreter threads. These threads can be used explicitly and implicitly.
+Snce 5.6.0, Perl has had support for a new type of threads called
+interpreter threads ('ithreads). These threads can be used explicitly
Ithreads work by cloning the data tree so that no data is shared
-between different threads. These threads can be used using the threads
+between different threads. These threads can be used by using the threads
module or by doing fork() on win32 (fake fork() support). When a
thread is cloned all Perl data is cloned, however non-Perl data cannot
be cloned automatically. Perl after 5.7.2 has support for the C<CLONE>