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
my $bar = $foo;
bless $foo, 'Class';
- print blessed( $bar ); # prints "Class"
+ print blessed( $bar ) // 'not blessed'; # prints "Class"
$bar = "some other value";
- print blessed( $bar ); # prints undef
+ print blessed( $bar ) // 'not blessed'; # prints "not blessed"
When we call C<bless> on a variable, we are actually blessing the
underlying data structure that the variable refers to. We are not
contains a list of that class's parent classes, if any. This array is
examined when Perl does method resolution, which we will cover later.
-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
-parent classes and make sure that the package doesn't inherit from
-itself.
+Calling methods from a package means it must be loaded, of course, so
+you will often want to load a module and add it to C<@ISA> at the same
+time. You can do so in a single step using the L<parent> pragma.
+(In older code you may encounter the L<base> pragma, which is nowadays
+discouraged except when you have to work with the equally discouraged
+L<fields> pragma.)
However the parent classes are set, the package's C<@ISA> variable will
-contain a list of those parents.
+contain a list of those parents. This is simply a list of scalars, each
+of which is a string that corresponds to a package name.
All classes inherit from the L<UNIVERSAL> class implicitly. The
L<UNIVERSAL> class is implemented by the Perl core, and provides
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
sub speak {
my $self = shift;
- $self->SUPER::speak();
-
say 'A';
}
package B;
- use parent 'A';
+ use parent -norequire, 'A';
sub speak {
my $self = shift;
package C;
- use parent 'B';
+ use parent -norequire, 'B';
sub speak {
my $self = shift;
X<multiple inheritance>
Multiple inheritance often indicates a design problem, but Perl always
-give you enough rope to hang yourself with if you really need to.
+gives you enough rope to hang yourself with if you ask for it.
To declare multiple parents, you simply need to pass multiple class
names to C<use parent>:
So given the diagram above, Perl will search C<Child>, C<Father>,
C<PaternalGrandparent>, C<SharedGreatGrandParent>, C<Mother>, and
-finally C<MaternalGrandparent> This is a problem because now we're
+finally C<MaternalGrandparent>. This may be a problem because now we're
looking in C<SharedGreatGrandParent> I<before> we've checked all its
derived classes (i.e. before we tried C<Mother> and
C<MaternalGrandparent>).
use parent 'Father', 'Mother';
This pragma lets you switch to the "C3" resolution order. In simple
-terms, "C3" order ensures that parent classes are never searched before
-child classes, so Perl will now search: C<Child>, C<Father>,
+terms, "C3" order ensures that shared parent classes are never searched
+before child classes, so Perl will now search: C<Child>, C<Father>,
C<PaternalGrandparent>, C<Mother> C<MaternalGrandparent>, and finally
C<SharedGreatGrandParent>. Note however that this is not
"breadth-first" searching: All the C<Father> ancestors (except the
itself. Remember, under the hood, this object is still just a hash.
Later, we'll write accessors to manipulate this data.
-For our File::MP3 class, we can check to make sure that the path we're
-given ends with ".mp3":
+For our C<File::MP3> class, we can check to make sure that the path
+we're given ends with ".mp3":
package File::MP3;
attribute is acceptable.
Finally, using accessors makes inheritance much simpler. Subclasses can
-use the accessors rather than having to know the inner details of the
-object.
+use the accessors rather than having to know how a parent class is
+implemented internally.
=head3 Writing Accessors
X<accessor>
As with constructors, Perl provides no special accessor declaration
-syntax, so classes must write them by hand. There are two common types
-of accessors, read-only and read-write.
+syntax, so classes must provide explicitly written accessor methods.
+There are two common types of accessors, read-only and read-write.
A simple read-only accessor simply gets the value of a single
attribute:
=head2 Method Call Variations
X<method>
-Perl supports several other ways to call methods besides the typical
-C<< $object->method() >> pattern we've seen so far.
+Perl supports several other ways to call methods besides the C<<
+$object->method() >> usage we've seen so far.
+
+=head3 Method Names with a Fully Qualified Name
+
+Perl allows you to call methods using their fully qualified name (the
+package and method name):
+
+ my $mp3 = File::MP3->new( 'Regin.mp3', $data );
+ $mp3->File::save();
+
+When you a fully qualified method name like C<File::save>, the method
+resolution search for the C<save> method starts in the C<File> class,
+skipping any C<save> method the C<File::MP3> class may have defined. It
+still searches the C<File> class's parents if necessary.
+
+While this feature is most commonly used to explicitly call methods
+inherited from an ancestor class, there is no technical restriction
+that enforces this:
+
+ my $obj = Tree->new();
+ $obj->Dog::bark();
+
+This calls the C<bark> method from class C<Dog> on an object of class
+C<Tree>, even if the two classes are completely unrelated. Use this
+with great care.
+
+The C<SUPER> pseudo-class that was described earlier is I<not> the same
+as calling a method with a fully-qualified name. See the earlier
+L</Inheritance> section for details.
=head3 Method Names as Strings
$object->$meth();
}
-=head3 Deferencing Method Call
+=head3 Dereferencing Method Call
Perl also lets you use a dereferenced scalar reference in a method
call. That's a mouthful, so let's look at some code:
$file->${ \'save' };
$file->${ returns_scalar_ref() };
$file->${ \( returns_scalar() ) };
+ $file->${ returns_ref_to_sub_ref() };
This works if the dereference produces a string I<or> a subroutine
reference.
X<invocation>
Because Perl allows you to use barewords for package names and
-subroutine names, it can sometimes guess wrong about what you intend a
-bareword to be. For example, the construct C<< Class->new() >> can be
+subroutine names, it sometimes interprets a bareword's meaning
+incorrectly. For example, the construct C<< Class->new() >> can be
interpreted as either C<< 'Class'->new() >> or C<< Class()->new() >>.
In English, that second interpretation reads as "call a subroutine
-named Class(), then call new() as a method on the return value". If
-there is a subroutine named C<Class()> in the current namespace, Perl
-will always interpret C<Class->new()> as the second alterative: a call
-to C<new()> on the object returned by a call to C<Class()>
+named Class(), then call new() as a method on the return value of
+Class()". If there is a subroutine named C<Class()> in the current
+namespace, Perl will always interpret C<< Class->new() >> as the second
+alternative: a call to C<new()> on the object returned by a call to
+C<Class()>
You can force Perl to use the first interpretation (i.e. as a method
call on the class named "Class") in two ways. First, you can append a
=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.
We recommend that you avoid this syntax, for several reasons.
First, it can be confusing to read. In the above example, it's not
-clear if C<save> is a method or simply a subroutine that expects a file
-object as its first argument.
+clear if C<save> is a method provided by the C<File> class or simply a
+subroutine that expects a file object as its first argument.
When used with class methods, the problem is even worse. Because Perl
allows subroutine names to be written as barewords, Perl has to guess
use Scalar::Util 'blessed';
- if ( blessed($thing) ) { ... }
+ if ( defined blessed($thing) ) { ... }
If C<$thing> refers to an object, then this function returns the name
-of the package the object has been blessed into. Note that the example
-above will return false if C<$thing> has been blessed into a class
-named "0". If C<$thing> doesn't contain a reference to a blessed
-object, the C<blessed> function returns false (specifically: C<undef>).
+of the package the object has been blessed into. If C<$thing> doesn't
+contain a reference to a blessed object, the C<blessed> function
+returns C<undef>.
+
+Note that C<blessed($thing)> will also return false if C<$thing> has
+been blessed into a class named "0". This is a possible, but quite
+pathological. Don't create a class named "0" unless you know what
+you're doing.
Similarly, Perl's built-in C<ref> function treats a reference to a
blessed object specially. If you call C<ref($thing)> and C<$thing>
The C<isa> method returns I<true> if the object is a member of the
class in C<$class>, or a member of a subclass of C<$class>.
+If you override this method, it should never throw an exception.
+
=item DOES($role)
X<DOES>
provided for use by object system extensions that implement roles, like
C<Moose> and C<Role::Tiny>.
-You can also override C<DOES> directly in your own classes.
+You can also override C<DOES> directly in your own classes. If you
+override this method, it should never throw an exception.
=item can($method)
X<can>
overload C<can> to return a subroutine reference for methods which your
C<AUTOLOAD> method handles.
+If you override this method, it should never throw an exception.
+
=item VERSION($need)
X<VERSION>
X<AUTOLOAD>
If you call a method that doesn't exist in a class, Perl will throw an
-error. However, if that class or any of its parent classes defined an
-C<AUTOLOAD> method, that method will be called instead.
+error. However, if that class or any of its parent classes defines an
+C<AUTOLOAD> method, that C<AUTOLOAD> method is called instead.
-This is called as a regular method, and the caller will not know the
-difference. Whatever value your C<AUTOLOAD> method returns is given to
-the caller.
+C<AUTOLOAD> is called as a regular method, and the caller will not know
+the difference. Whatever value your C<AUTOLOAD> method returns is
+returned to the caller.
The fully qualified method name that was called is available in the
C<$AUTOLOAD> package global for your class. Since this is a global, if
under the L<strict> pragma.
As the comment says, this is not a good way to implement accessors.
-It's slow and too clever by far. See L<perlootut> for recommendations
-on OO coding in Perl.
+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.
If your class does have an C<AUTOLOAD> method, we strongly recommend
that you override C<can> in your class as well. Your overridden C<can>
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
If your C<DESTROY> method issues a warning during global destruction,
the Perl interpreter will append the string " during global
-destruction" the warning.
+destruction" to the warning.
During global destruction, Perl will always garbage collect objects
before unblessed references. See L<perlhacktips/PERL_DESTRUCT_LEVEL>
https://perl5.git.perl.org / perl5.git / blobdiff