Fix typos (spelling errors) in lib/*

# New Ticket Created by  (Peter J. Acklam)
# Please include the string:  [perl #81890]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81890 >

Signed-off-by: Abigail <abigail@abigail.be>

1 files changed, 3 insertions, 3 deletions

diff --git a/lib/UNIVERSAL.pm b/lib/UNIVERSAL.pm
index 89604626c4..f314d9c582 100644
--- a/lib/UNIVERSAL.pm
+++ b/lib/UNIVERSAL.pm
@@ -99,7 +99,7 @@ If you're not sure what you have (the C<VAL> case), wrap the method call in an
 C<eval> block to catch the exception if C<VAL> is undefined.
 
 If you want to be sure that you're calling C<isa> as a method, not a class,
-check the invocant with C<blessed> from L<Scalar::Util> first:
+check the invocand with C<blessed> from L<Scalar::Util> first:
 
   use Scalar::Util 'blessed';
 
@@ -119,7 +119,7 @@ itself.  For example, logging or serialization may be roles.
 C<DOES> and C<isa> are similar, in that if either is true, you know that the
 object or class on which you call the method can perform specific behavior.
 However, C<DOES> is different from C<isa> in that it does not care I<how> the
-invocant performs the operations, merely that it does.  (C<isa> of course
+invocand performs the operations, merely that it does.  (C<isa> of course
 mandates an inheritance relationship.  Other relationships include aggregation,
 delegation, and mocking.)
 
@@ -157,7 +157,7 @@ calling the coderef will cause an error.
 
 You may call C<can> as a class (static) method or an object method.
 
-Again, the same rule about having a valid invocant applies -- use an C<eval>
+Again, the same rule about having a valid invocand applies -- use an C<eval>
 block or C<blessed> if you need to be extra paranoid.
 
 =item C<VERSION ( [ REQUIRE ] )>