From: Vincent Pit <vince@profvince.com>
Date: Mon, 16 Aug 2010 13:20:26 +0000 (+0200)
Subject: Typos
X-Git-Tag: v0.22~4
X-Git-Url: http://git.vpit.fr/?a=commitdiff_plain;h=ec48b957f1ab41d61e97f77b104a5b41f616af32;p=perl%2Fmodules%2Findirect.git

Typos
---

diff --git a/lib/indirect.pm b/lib/indirect.pm
index 6cdf32a..01eed4f 100644
--- a/lib/indirect.pm
+++ b/lib/indirect.pm
@@ -49,7 +49,7 @@ BEGIN {
 
 When enabled (or disabled as some may prefer to say, since you actually turn it on by calling C<no indirect>), this pragma warns about indirect object syntax constructs that may have slipped into your code.
 
-This syntax is now considered harmful, since its parsing has many quirks and its use is error prone (when C<swoosh> isn't defined, C<swoosh $x> actually compiles to C<< $x->swoosh >>).
+This syntax is now considered harmful, since its parsing has many quirks and its use is error prone (when C<swoosh> is not defined, C<swoosh $x> actually compiles to C<< $x->swoosh >>).
 In L<http://www.shadowcat.co.uk/blog/matt-s-trout/indirect-but-still-fatal>, Matt S. Trout gives an example of an indirect construct that can cause a particularly bewildering error.
 
 It currently does not warn for core functions (C<print>, C<say>, C<exec> or C<system>).
@@ -175,11 +175,11 @@ In this case, the pragma will always be considered to be thread-safe, and as suc
 This is useful for disabling C<indirect> in production environments.
 
 Note that clearing this variable after C<indirect> was loaded has no effect.
-If you want to reenable the pragma later, you also need to reload it by deleting the C<'indirect.pm'> entry from C<%INC>.
+If you want to re-enable the pragma later, you also need to reload it by deleting the C<'indirect.pm'> entry from C<%INC>.
 
 =head1 CAVEATS
 
-The implementation was tweaked to work around several limitations of vanilla C<perl> pragmas : it's thread safe, and doesn't suffer from a C<perl 5.8.x-5.10.0> bug that causes all pragmas to propagate into C<require>d scopes.
+The implementation was tweaked to work around several limitations of vanilla C<perl> pragmas : it's thread safe, and does not suffer from a C<perl 5.8.x-5.10.0> bug that causes all pragmas to propagate into C<require>d scopes.
 
 C<meth $obj> (no semicolon) at the end of a file won't be seen as an indirect object syntax, although it will as soon as there is another token before the end (as in C<meth $obj;> or C<meth $obj 1>).