Minor perlfaq7 tweaks
authorFather Chrysostomos <sprout@cpan.org>
Sat, 19 Feb 2011 19:49:31 +0000 (11:49 -0800)
committerFather Chrysostomos <sprout@cpan.org>
Sun, 20 Feb 2011 01:42:20 +0000 (17:42 -0800)
pod/perlfaq7.pod

index 5d7a1e8..a4f8e7f 100644 (file)
@@ -29,7 +29,8 @@ They are type specifiers, as detailed in L<perldata>:
        * for all types of that symbol name.  In version 4 you used them like
          pointers, but in modern perls you can just use references.
 
-There are couple of other symbols that you're likely to encounter that aren't
+There are a couple of other symbols that
+you're likely to encounter that aren't
 really type specifiers:
 
        <> are used for inputting a record from a filehandle.
@@ -332,7 +333,7 @@ package:
                sub next_id { ++$id }
        }
 
-This is discussed in more detail in L<perlsub>, see the entry on
+This is discussed in more detail in L<perlsub>; see the entry on
 I<Persistent Private Variables>.
 
 =head2 What is variable suicide and how can I prevent it?
@@ -553,7 +554,7 @@ For instance:
 
 Notice how at no point does the value "private" get printed.  That's
 because $var only has that value within the block of the lexical()
-function, and it is hidden from called subroutine.
+function, and it is hidden from the called subroutine.
 
 In summary, local() doesn't make what you think of as private, local
 variables.  It gives a global variable a temporary value.  my() is
@@ -796,7 +797,7 @@ out L<perltoot> for details about any of the above cases.  You may
 also use C<print ref($object)> to find out the class C<$object> was
 blessed into.
 
-Another possible reason for problems is because you've used the
+Another possible reason for problems is that you've used the
 indirect object syntax (eg, C<find Guru "Samy">) on a class name
 before Perl has seen that such a package exists.  It's wisest to make
 sure your packages are all defined before you start using them, which
@@ -942,8 +943,8 @@ altogether.  Global variables are bad because they can easily collide
 accidentally and in general make for non-scalable and confusing code.
 
 Symbolic references are forbidden under the C<use strict> pragma.
-They are not true references and consequently are not reference counted
-or garbage collected.
+They are not true references and consequently are not reference-counted
+or garbage-collected.
 
 The other reason why using a variable to hold the name of another
 variable is a bad idea is that the question often stems from a lack of
@@ -980,7 +981,7 @@ make it less confusing, like bracketed percent symbols, etc.
        $str =~ s/%(\w+)%/$USER_VARS{$1}/g;   # no /e here at all
 
 Another reason that folks sometimes think they want a variable to
-contain the name of a variable is because they don't know how to build
+contain the name of a variable is that they don't know how to build
 proper data structures using hashes.  For example, let's say they
 wanted two hashes in their program: %fred and %barney, and that they
 wanted to use another scalar variable to refer to those by name.
@@ -1001,7 +1002,7 @@ And just use a multilevel hash to start with.
 
 The only times that you absolutely I<must> use symbolic references are
 when you really must refer to the symbol table.  This may be because it's
-something that can't take a real reference to, such as a format name.
+something that one can't take a real reference to, such as a format name.
 Doing so may also be important for method calls, since these always go
 through the symbol table for resolution.
 
@@ -1017,8 +1018,8 @@ can play around with the symbol table.  For example:
 All those functions (red(), blue(), green(), etc.) appear to be separate,
 but the real code in the closure actually was compiled only once.
 
-So, sometimes you might want to use symbolic references to directly
-manipulate the symbol table.  This doesn't matter for formats, handles, and
+So, sometimes you might want to use symbolic references to manipulate
+the symbol table directly.  This doesn't matter for formats, handles, and
 subroutines, because they are always global--you can't use my() on them.
 For scalars, arrays, and hashes, though--and usually for subroutines--
 you probably only want to use hard references.