Note, however, that (unlike most other OO languages) Perl does not
ensure or enforce encapsulation in any way. If you want objects to
actually I<be> opaque you need to arrange for that yourself. This can
-be done in a varierty of ways, including using L<"Inside-Out objects">
+be done in a variety of ways, including using L<"Inside-Out objects">
or modules from CPAN.
=head3 Objects Are Blessed; Variables Are Not
It is possible to manually set C<@ISA>, and you may see this in older
Perl code. Much older code also uses the L<base> pragma. For new code,
we recommend that you use the L<parent> pragma to declare your parents.
-This pragma will take care of setting C<@ISA>. It will also load the
+This pragma will take care of setting C<@ISA>. It will also load the
parent classes and make sure that the package doesn't inherit from
itself.
my $pod = File->new( 'perlobj.pod', $data );
$pod->save();
-The C<< -> >> syntax is also used when dereferencing a reference. It
+The C<< -> >> syntax is also used when dereferencing a reference. It
looks like the same operator, but these are two different operations.
When you call a method, the thing on the left side of the arrow is
=head3 Indirect Object Syntax
X<indirect object>
-B<Outside of the file handle case, use of this syntax is discouraged,
-as it can confuse the Perl interpreter. See below for more details.>
+B<Outside of the file handle case, use of this syntax is discouraged as
+it can confuse the Perl interpreter. See below for more details.>
-Perl suports another method invocation syntax called "indirect object"
+Perl supports another method invocation syntax called "indirect object"
notation. This syntax is called "indirect" because the method comes
before the object it is being invoked on.
Without the C<our $AUTOLOAD> declaration, this code will not compile
under the L<strict> pragma.
-As the comment says, this is not a good way to implement accessors.
+As the comment says, this is not a good way to implement accessors.
It's slow and too clever by far. However, you may see this as a way to
provide accessors in older Perl code. See L<perlootut> for
recommendations on OO coding in Perl.
Because C<DESTROY> methods can be called at any time, you should
localize any global variables you might update in your C<DESTROY>. In
particular, if you use C<eval {}> you should localize C<$@>, and if you
-use C<system> or backticks, you should localize C<$?>.
+use C<system> or backticks you should localize C<$?>.
If you define an C<AUTOLOAD> in your class, then Perl will call your
C<AUTOLOAD> to handle the C<DESTROY> method. You can prevent this by