|
perltoot - Tom's object-oriented tutorial for perl
|
perltoot - Tom's object-oriented tutorial for perl
Object-oriented programming is a big seller these days. Some managers
would rather have objects than sliced bread. Why is that? What's so
special about an object? Just what is an object anyway?
An object is nothing but a way of tucking away complex behaviours into
a neat little easy-to-use bundle. (This is what professors call
abstraction.) Smart people who have nothing to do but sit around for
weeks on end figuring out really hard problems make these nifty
objects that even regular people can use. (This is what professors call
software reuse.) Users (well, programmers) can play with this little
bundle all they want, but they aren't to open it up and mess with the
insides. Just like an expensive piece of hardware, the contract says
that you void the warranty if you muck with the cover. So don't do that.
The heart of objects is the class, a protected little private namespace
full of data and functions. A class is a set of related routines that
addresses some problem area. You can think of it as a user-defined type.
The Perl package mechanism, also used for more traditional modules,
is used for class modules as well. Objects ``live'' in a class, meaning
that they belong to some package.
More often than not, the class provides the user with little bundles.
These bundles are objects. They know whose class they belong to,
and how to behave. Users ask the class to do something, like ``give
me an object.'' Or they can ask one of these objects to do something.
Asking a class to do something for you is calling a class method.
Asking an object to do something for you is calling an object method.
Asking either a class (usually) or an object (sometimes) to give you
back an object is calling a constructor, which is just a
kind of method.
That's all well and good, but how is an object different from any other
Perl data type? Just what is an object really; that is, what's its
fundamental type? The answer to the first question is easy. An object
is different from any other data type in Perl in one and only one way:
you may dereference it using not merely string or numeric subscripts
as with simple arrays and hashes, but with named subroutine calls.
In a word, with methods.
The answer to the second question is that it's a reference, and not just
any reference, mind you, but one whose referent has been bless()ed
into a particular class (read: package). What kind of reference? Well,
the answer to that one is a bit less concrete. That's because in Perl
the designer of the class can employ any sort of reference they'd like
as the underlying intrinsic data type. It could be a scalar, an array,
or a hash reference. It could even be a code reference. But because
of its inherent flexibility, an object is usually a hash reference.
Before you create a class, you need to decide what to name it. That's
because the class (package) name governs the name of the file used to
house it, just as with regular modules. Then, that class (package)
should provide one or more ways to generate objects. Finally, it should
provide mechanisms to allow users of its objects to indirectly manipulate
these objects from a distance.
For example, let's make a simple Person class module. It gets stored in
the file Person.pm. If it were called a Happy::Person class, it would
be stored in the file Happy/Person.pm, and its package would become
Happy::Person instead of just Person. (On a personal computer not
running Unix or Plan 9, but something like MacOS or VMS, the directory
separator may be different, but the principle is the same.) Do not assume
any formal relationship between modules based on their directory names.
This is merely a grouping convenience, and has no effect on inheritance,
variable accessibility, or anything else.
For this module we aren't going to use Exporter, because we're
a well-behaved class module that doesn't export anything at all.
In order to manufacture objects, a class needs to have a constructor
method. A constructor gives you back not just a regular data type,
but a brand-new object in that class. This magic is taken care of by
the bless() function, whose sole purpose is to enable its referent to
be used as an object. Remember: being an object really means nothing
more than that methods may now be called against it.
While a constructor may be named anything you'd like, most Perl
programmers seem to like to call theirs new(). However, new() is not
a reserved word, and a class is under no obligation to supply such.
Some programmers have also been known to use a function with
the same name as the class as the constructor.
By far the most common mechanism used in Perl to represent a Pascal
record, a C struct, or a C++ class is an anonymous hash. That's because a
hash has an arbitrary number of data fields, each conveniently accessed by
an arbitrary name of your own devising.
If you were just doing a simple
struct-like emulation, you would likely go about it something like this:
$rec = {
name => "Jason",
age => 23,
peers => [ "Norbert", "Rhys", "Phineas"],
};
If you felt like it, you could add a bit of visual distinction
by up-casing the hash keys:
$rec = {
NAME => "Jason",
AGE => 23,
PEERS => [ "Norbert", "Rhys", "Phineas"],
};
And so you could get at $rec->{NAME} to find ``Jason'', or
@{ $rec->{PEERS} } to get at ``Norbert'', ``Rhys'', and ``Phineas''.
(Have you ever noticed how many 23-year-old programmers seem to
be named ``Jason'' these days? :-)
This same model is often used for classes, although it is not considered
the pinnacle of programming propriety for folks from outside the
class to come waltzing into an object, brazenly accessing its data
members directly. Generally speaking, an object should be considered
an opaque cookie that you use object methods to access. Visually,
methods look like you're dereffing a reference using a function name
instead of brackets or braces.
Some languages provide a formal syntactic interface to a class's methods,
but Perl does not. It relies on you to read the documentation of each
class. If you try to call an undefined method on an object, Perl won't
complain, but the program will trigger an exception while it's running.
Likewise, if you call a method expecting a prime number as its argument
with a non-prime one instead, you can't expect the compiler to catch this.
(Well, you can expect it all you like, but it's not going to happen.)
Let's suppose you have a well-educated user of your Person class,
someone who has read the docs that explain the prescribed
interface. Here's how they might use the Person class:
use Person;
$him = Person->new();
$him->name("Jason");
$him->age(23);
$him->peers( "Norbert", "Rhys", "Phineas" );
push @All_Recs, $him; # save object in array for later
printf "%s is %d years old.\n", $him->name, $him->age;
print "His peers are: ", join(", ", $him->peers), "\n";
printf "Last rec's name is %s\n", $All_Recs[-1]->name;
As you can see, the user of the class doesn't know (or at least, has no
business paying attention to the fact) that the object has one particular
implementation or another. The interface to the class and its objects
is exclusively via methods, and that's all the user of the class should
ever play with.
Still, someone has to know what's in the object. And that someone is
the class. It implements methods that the programmer uses to access
the object. Here's how to implement the Person class using the standard
hash-ref-as-an-object idiom. We'll make a class method called new() to
act as the constructor, and three object methods called name(), age(), and
peers() to get at per-object data hidden away in our anonymous hash.
package Person;
use strict;
##################################################
## the object constructor (simplistic version) ##
##################################################
sub new {
my $self = {};
$self->{NAME} = undef;
$self->{AGE} = undef;
$self->{PEERS} = [];
bless($self); # but see below
return $self;
}
##############################################
## methods to access per-object data ##
## ##
## With args, they set the value. Without ##
## any, they only retrieve it/them. ##
##############################################
sub name {
my $self = shift;
if (@_) { $self->{NAME} = shift }
return $self->{NAME};
}
sub age {
my $self = shift;
if (@_) { $self->{AGE} = shift }
return $self->{AGE};
}
sub peers {
my $self = shift;
if (@_) { @{ $self->{PEERS} } = @_ }
return @{ $self->{PEERS} };
}
1; # so the require or use succeeds
We've created three methods to access an object's data, name(), age(),
and peers(). These are all substantially similar. If called with an
argument, they set the appropriate field; otherwise they return the
value held by that field, meaning the value of that hash key.
Even though at this point you may not even know what it means, someday
you're going to worry about inheritance. (You can safely ignore this
for now and worry about it later if you'd like.) To ensure that this
all works out smoothly, you must use the double-argument form of bless().
The second argument is the class into which the referent will be blessed.
By not assuming our own class as the default second argument and instead
using the class passed into us, we make our constructor inheritable.
While we're at it, let's make our constructor a bit more flexible.
Rather than being uniquely a class method, we'll set it up so that
it can be called as either a class method or an object
method. That way you can say:
$me = Person->new();
$him = $me->new();
To do this, all we have to do is check whether what was passed in
was a reference or not. If so, we were invoked as an object method,
and we need to extract the package (class) using the ref() function.
If not, we just use the string passed in as the package name
for blessing our referent.
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = {};
$self->{NAME} = undef;
$self->{AGE} = undef;
$self->{PEERS} = [];
bless ($self, $class);
return $self;
}
That's about all there is for constructors. These methods bring objects
to life, returning neat little opaque bundles to the user to be used in
subsequent method calls.
Every story has a beginning and an end. The beginning of the object's
story is its constructor, explicitly called when the object comes into
existence. But the ending of its story is the destructor, a method
implicitly called when an object leaves this life. Any per-object
clean-up code is placed in the destructor, which must (in Perl) be called
DESTROY.
If constructors can have arbitrary names, then why not destructors?
Because while a constructor is explicitly called, a destructor is not.
Destruction happens automatically via Perl's garbage collection (GC)
system, which is a quick but somewhat lazy reference-based GC system.
To know what to call, Perl insists that the destructor be named DESTROY.
Perl's notion of the right time to call a destructor is not well-defined
currently, which is why your destructors should not rely on when they are
called.
Why is DESTROY in all caps? Perl on occasion uses purely uppercase
function names as a convention to indicate that the function will
be automatically called by Perl in some way. Others that are called
implicitly include BEGIN, END, AUTOLOAD, plus all methods used by
tied objects, described in the perltie manpage.
In really good object-oriented programming languages, the user doesn't
care when the destructor is called. It just happens when it's supposed
to. In low-level languages without any GC at all, there's no way to
depend on this happening at the right time, so the programmer must
explicitly call the destructor to clean up memory and state, crossing
their fingers that it's the right time to do so. Unlike C++, an
object destructor is nearly never needed in Perl, and even when it is,
explicit invocation is uncalled for. In the case of our Person class,
we don't need a destructor because Perl takes care of simple matters
like memory deallocation.
The only situation where Perl's reference-based GC won't work is
when there's a circularity in the data structure, such as:
$this->{WHATEVER} = $this;
In that case, you must delete the self-reference manually if you expect
your program not to leak memory. While admittedly error-prone, this is
the best we can do right now. Nonetheless, rest assured that when your
program is finished, its objects' destructors are all duly called.
So you are guaranteed that an object eventually gets properly
destroyed, except in the unique case of a program that never exits.
(If you're running Perl embedded in another application, this full GC
pass happens a bit more frequently--whenever a thread shuts down.)
The methods we've talked about so far have either been constructors or
else simple ``data methods'', interfaces to data stored in the object.
These are a bit like an object's data members in the C++ world, except
that strangers don't access them as data. Instead, they should only
access the object's data indirectly via its methods. This is an
important rule: in Perl, access to an object's data should only
be made through methods.
Perl doesn't impose restrictions on who gets to use which methods.
The public-versus-private distinction is by convention, not syntax.
(Well, unless you use the Alias module described below in
Data Members as Variables.) Occasionally you'll see method names beginning or ending
with an underscore or two. This marking is a convention indicating
that the methods are private to that class alone and sometimes to its
closest acquaintances, its immediate subclasses. But this distinction
is not enforced by Perl itself. It's up to the programmer to behave.
There's no reason to limit methods to those that simply access data.
Methods can do anything at all. The key point is that they're invoked
against an object or a class. Let's say we'd like object methods that
do more than fetch or set one particular field.
sub exclaim {
my $self = shift;
return sprintf "Hi, I'm %s, age %d, working with %s",
$self->{NAME}, $self->{AGE}, join(", ", @{$self->{PEERS}});
}
Or maybe even one like this:
sub happy_birthday {
my $self = shift;
return ++$self->{AGE};
}
Some might argue that one should go at these this way:
sub exclaim {
my $self = shift;
return sprintf "Hi, I'm %s, age %d, working with %s",
$self->name, $self->age, join(", ", $self->peers);
}
sub happy_birthday {
my $self = shift;
return $self->age( $self->age() + 1 );
}
But since these methods are all executing in the class itself, this
may not be critical. There are tradeoffs to be made. Using direct
hash access is faster (about an order of magnitude faster, in fact), and
it's more convenient when you want to interpolate in strings. But using
methods (the external interface) internally shields not just the users of
your class but even you yourself from changes in your data representation.
What about ``class data'', data items common to each object in a class?
What would you want that for? Well, in your Person class, you might
like to keep track of the total people alive. How do you implement that?
You could make it a global variable called $Person::Census. But about
only reason you'd do that would be if you wanted people to be able to
get at your class data directly. They could just say $Person::Census
and play around with it. Maybe this is ok in your design scheme.
You might even conceivably want to make it an exported variable. To be
exportable, a variable must be a (package) global. If this were a
traditional module rather than an object-oriented one, you might do that.
While this approach is expected in most traditional modules, it's
generally considered rather poor form in most object modules. In an
object module, you should set up a protective veil to separate interface
from implementation. So provide a class method to access class data
just as you provide object methods to access object data.
So, you could still keep $Census as a package global and rely upon
others to honor the contract of the module and therefore not play around
with its implementation. You could even be supertricky and make $Census a
tied object as described in the perltie manpage, thereby intercepting all accesses.
But more often than not, you just want to make your class data a
file-scoped lexical. To do so, simply put this at the top of the file:
my $Census = 0;
Even though the scope of a my() normally expires when the block in which
it was declared is done (in this case the whole file being required or
used), Perl's deep binding of lexical variables guarantees that the
variable will not be deallocated, remaining accessible to functions
declared within that scope. This doesn't work with global variables
given temporary values via local(), though.
Irrespective of whether you leave $Census a package global or make
it instead a file-scoped lexical, you should make these
changes to your Person::new() constructor:
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = {};
$Census++;
$self->{NAME} = undef;
$self->{AGE} = undef;
$self->{PEERS} = [];
bless ($self, $class);
return $self;
}
sub population {
return $Census;
}
Now that we've done this, we certainly do need a destructor so that
when Person is destroyed, the $Census goes down. Here's how
this could be done:
sub DESTROY { --$Census }
Notice how there's no memory to deallocate in the destructor? That's
something that Perl takes care of for you all by itself.
Alternatively, you could use the Class::Data::Inheritable module from
CPAN.
It turns out that this is not really a good way to go about handling
class data. A good scalable rule is that you must never reference class
data directly from an object method. Otherwise you aren't building a
scalable, inheritable class. The object must be the rendezvous point
for all operations, especially from an object method. The globals
(class data) would in some sense be in the ``wrong'' package in your
derived classes. In Perl, methods execute in the context of the class
they were defined in, not that of the object that triggered them.
Therefore, namespace visibility of package globals in methods is unrelated
to inheritance.
Got that? Maybe not. Ok, let's say that some other class ``borrowed''
(well, inherited) the DESTROY method as it was defined above. When those
objects are destroyed, the original $Census variable will be altered,
not the one in the new class's package namespace. Perhaps this is what
you want, but probably it isn't.
Here's how to fix this. We'll store a reference to the data in the
value accessed by the hash key ``_CENSUS''. Why the underscore? Well,
mostly because an initial underscore already conveys strong feelings
of magicalness to a C programmer. It's really just a mnemonic device
to remind ourselves that this field is special and not to be used as
a public data member in the same way that NAME, AGE, and PEERS are.
(Because we've been developing this code under the strict pragma, prior
to perl version 5.004 we'll have to quote the field name.)
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = {};
$self->{NAME} = undef;
$self->{AGE} = undef;
$self->{PEERS} = [];
# "private" data
$self->{"_CENSUS"} = \$Census;
bless ($self, $class);
++ ${ $self->{"_CENSUS"} };
return $self;
}
sub population {
my $self = shift;
if (ref $self) {
return ${ $self->{"_CENSUS"} };
} else {
return $Census;
}
}
sub DESTROY {
my $self = shift;
-- ${ $self->{"_CENSUS"} };
}
It's common for a class to have a debugging mechanism. For example,
you might want to see when objects are created or destroyed. To do that,
add a debugging variable as a file-scoped lexical. For this, we'll pull
in the standard Carp module to emit our warnings and fatal messages.
That way messages will come out with the caller's filename and
line number instead of our own; if we wanted them to be from our own
perspective, we'd just use die() and warn() directly instead of croak()
and carp() respectively.
use Carp;
my $Debugging = 0;
Now add a new class method to access the variable.
sub debug {
my $class = shift;
if (ref $class) { confess "Class method called as object method" }
unless (@_ == 1) { confess "usage: CLASSNAME->debug(level)" }
$Debugging = shift;
}
Now fix up DESTROY to murmur a bit as the moribund object expires:
sub DESTROY {
my $self = shift;
if ($Debugging) { carp "Destroying $self " . $self->name }
-- ${ $self->{"_CENSUS"} };
}
One could conceivably make a per-object debug state. That
way you could call both of these:
Person->debug(1); # entire class
$him->debug(1); # just this object
To do so, we need our debugging method to be a ``bimodal'' one, one that
works on both classes and objects. Therefore, adjust the debug()
and DESTROY methods as follows:
sub debug {
my $self = shift;
confess "usage: thing->debug(level)" unless @_ == 1;
my $level = shift;
if (ref($self)) {
$self->{"_DEBUG"} = $level; # just myself
} else {
$Debugging = $level; # whole class
}
}
sub DESTROY {
my $self = shift;
if ($Debugging || $self->{"_DEBUG"}) {
carp "Destroying $self " . $self->name;
}
-- ${ $self->{"_CENSUS"} };
}
What happens if a derived class (which we'll call Employee) inherits
methods from this Person base class? Then Employee->debug(), when called
as a class method, manipulates $Person::Debugging not $Employee::Debugging.
The object destructor handles the death of each distinct object. But sometimes
you want a bit of cleanup when the entire class is shut down, which
currently only happens when the program exits. To make such a
class destructor, create a function in that class's package named
END. This works just like the END function in traditional modules,
meaning that it gets called whenever your program exits unless it execs
or dies of an uncaught signal. For example,
sub END {
if ($Debugging) {
print "All persons are going away now.\n";
}
}
When the program exits, all the class destructors (END functions) are
be called in the opposite order that they were loaded in (LIFO order).
And there you have it: we've just shown you the implementation of this
Person class. Its interface would be its documentation. Usually this
means putting it in pod (``plain old documentation'') format right there
in the same file. In our Person example, we would place the following
docs anywhere in the Person.pm file. Even though it looks mostly like
code, it's not. It's embedded documentation such as would be used by
the pod2man, pod2html, or pod2text programs. The Perl compiler ignores
pods entirely, just as the translators ignore code. Here's an example of
some pods describing the informal interface:
=head1 NAME
Person - class to implement people
=head1 SYNOPSIS
use Person;
#################
# class methods #
#################
$ob = Person->new;
$count = Person->population;
#######################
# object data methods #
#######################
### get versions ###
$who = $ob->name;
$years = $ob->age;
@pals = $ob->peers;
### set versions ###
$ob->name("Jason");
$ob->age(23);
$ob->peers( "Norbert", "Rhys", "Phineas" );
########################
# other object methods #
########################
$phrase = $ob->exclaim;
$ob->happy_birthday;
=head1 DESCRIPTION
The Person class implements dah dee dah dee dah....
That's all there is to the matter of interface versus implementation.
A programmer who opens up the module and plays around with all the private
little shiny bits that were safely locked up behind the interface contract
has voided the warranty, and you shouldn't worry about their fate.
Suppose you later want to change the class to implement better names.
Perhaps you'd like to support both given names (called Christian names,
irrespective of one's religion) and family names (called surnames), plus
nicknames and titles. If users of your Person class have been properly
accessing it through its documented interface, then you can easily change
the underlying implementation. If they haven't, then they lose and
it's their fault for breaking the contract and voiding their warranty.
To do this, we'll make another class, this one called Fullname. What's
the Fullname class look like? To answer that question, you have to
first figure out how you want to use it. How about we use it this way:
$him = Person->new();
$him->fullname->title("St");
$him->fullname->christian("Thomas");
$him->fullname->surname("Aquinas");
$him->fullname->nickname("Tommy");
printf "His normal name is %s\n", $him->name;
printf "But his real name is %s\n", $him->fullname->as_string;
Ok. To do this, we'll change Person::new() so that it supports
a full name field this way:
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = {};
$self->{FULLNAME} = Fullname->new();
$self->{AGE} = undef;
$self->{PEERS} = [];
$self->{"_CENSUS"} = \$Census;
bless ($self, $class);
++ ${ $self->{"_CENSUS"} };
return $self;
}
sub fullname {
my $self = shift;
return $self->{FULLNAME};
}
Then to support old code, define Person::name() this way:
sub name {
my $self = shift;
return $self->{FULLNAME}->nickname(@_)
|| $self->{FULLNAME}->christian(@_);
}
Here's the Fullname class. We'll use the same technique
of using a hash reference to hold data fields, and methods
by the appropriate name to access them:
package Fullname;
use strict;
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = {
TITLE => undef,
CHRISTIAN => undef,
SURNAME => undef,
NICK => undef,
};
bless ($self, $class);
return $self;
}
sub christian {
my $self = shift;
if (@_) { $self->{CHRISTIAN} = shift }
return $self->{CHRISTIAN};
}
sub surname {
my $self = shift;
if (@_) { $self->{SURNAME} = shift }
return $self->{SURNAME};
}
sub nickname {
my $self = shift;
if (@_) { $self->{NICK} = shift }
return $self->{NICK};
}
sub title {
my $self = shift;
if (@_) { $self->{TITLE} = shift }
return $self->{TITLE};
}
sub as_string {
my $self = shift;
my $name = join(" ", @$self{'CHRISTIAN', 'SURNAME'});
if ($self->{TITLE}) {
$name = $self->{TITLE} . " " . $name;
}
return $name;
}
1;
Finally, here's the test program:
#!/usr/bin/perl -w
use strict;
use Person;
sub END { show_census() }
sub show_census () {
printf "Current population: %d\n", Person->population;
}
Person->debug(1);
show_census();
my $him = Person->new();
$him->fullname->christian("Thomas");
$him->fullname->surname("Aquinas");
$him->fullname->nickname("Tommy");
$him->fullname->title("St");
$him->age(1);
printf "%s is really %s.\n", $him->name, $him->fullname;
printf "%s's age: %d.\n", $him->name, $him->age;
$him->happy_birthday;
printf "%s's age: %d.\n", $him->name, $him->age;
show_census();
Object-oriented programming systems all support some notion of
inheritance. Inheritance means allowing one class to piggy-back on
top of another one so you don't have to write the same code again and
again. It's about software reuse, and therefore related to Laziness,
the principal virtue of a programmer. (The import/export mechanisms in
traditional modules are also a form of code reuse, but a simpler one than
the true inheritance that you find in object modules.)
Sometimes the syntax of inheritance is built into the core of the
language, and sometimes it's not. Perl has no special syntax for
specifying the class (or classes) to inherit from. Instead, it's all
strictly in the semantics. Each package can have a variable called @ISA,
which governs (method) inheritance. If you try to call a method on an
object or class, and that method is not found in that object's package,
Perl then looks to @ISA for other packages to go looking through in
search of the missing method.
Like the special per-package variables recognized by Exporter (such as
@EXPORT, @EXPORT_OK, @EXPORT_FAIL, %EXPORT_TAGS, and $VERSION), the @ISA
array must be a package-scoped global and not a file-scoped lexical
created via my(). Most classes have just one item in their @ISA array.
In this case, we have what's called ``single inheritance'', or SI for short.
Consider this class:
package Employee;
use Person;
@ISA = ("Person");
1;
Not a lot to it, eh? All it's doing so far is loading in another
class and stating that this one will inherit methods from that
other class if need be. We have given it none of its own methods.
We rely upon an Employee to behave just like a Person.
Setting up an empty class like this is called the ``empty subclass test'';
that is, making a derived class that does nothing but inherit from a
base class. If the original base class has been designed properly,
then the new derived class can be used as a drop-in replacement for the
old one. This means you should be able to write a program like this:
use Employee;
my $empl = Employee->new();
$empl->name("Jason");
$empl->age(23);
printf "%s is age %d.\n", $empl->name, $empl->age;
By proper design, we mean always using the two-argument form of bless(),
avoiding direct access of global data, and not exporting anything. If you
look back at the Person::new() function we defined above, we were careful
to do that. There's a bit of package data used in the constructor,
but the reference to this is stored on the object itself and all other
methods access package data via that reference, so we should be ok.
What do we mean by the Person::new() function -- isn't that actually
a method? Well, in principle, yes. A method is just a function that
expects as its first argument a class name (package) or object
(blessed reference). Person::new() is the function that both the
Person->new() method and the Employee->new() method end
up calling. Understand that while a method call looks a lot like a
function call, they aren't really quite the same, and if you treat them
as the same, you'll very soon be left with nothing but broken programs.
First, the actual underlying calling conventions are different: method
calls get an extra argument. Second, function calls don't do inheritance,
but methods do.
Method Call Resulting Function Call
----------- ------------------------
Person->new() Person::new("Person")
Employee->new() Person::new("Employee")
So don't use function calls when you mean to call a method.
If an employee is just a Person, that's not all too very interesting.
So let's add some other methods. We'll give our employee
data fields to access their salary, their employee ID, and their
start date.
If you're getting a little tired of creating all these nearly identical
methods just to get at the object's data, do not despair. Later,
we'll describe several different convenience mechanisms for shortening
this up. Meanwhile, here's the straight-forward way:
sub salary {
my $self = shift;
if (@_) { $self->{SALARY} = shift }
return $self->{SALARY};
}
sub id_number {
my $self = shift;
if (@_) { $self->{ID} = shift }
return $self->{ID};
}
sub start_date {
my $self = shift;
if (@_) { $self->{START_DATE} = shift }
return $self->{START_DATE};
}
What happens when both a derived class and its base class have the same
method defined? Well, then you get the derived class's version of that
method. For example, let's say that we want the peers() method called on
an employee to act a bit differently. Instead of just returning the list
of peer names, let's return slightly different strings. So doing this:
$empl->peers("Peter", "Paul", "Mary");
printf "His peers are: %s\n", join(", ", $empl->peers);
will produce:
His peers are: PEON=PETER, PEON=PAUL, PEON=MARY
To do this, merely add this definition into the Employee.pm file:
sub peers {
my $self = shift;
if (@_) { @{ $self->{PEERS} } = @_ }
return map { "PEON=\U$_" } @{ $self->{PEERS} };
}
There, we've just demonstrated the high-falutin' concept known in certain
circles as polymorphism. We've taken on the form and behaviour of
an existing object, and then we've altered it to suit our own purposes.
This is a form of Laziness. (Getting polymorphed is also what happens
when the wizard decides you'd look better as a frog.)
Every now and then you'll want to have a method call trigger both its
derived class (also known as ``subclass'') version as well as its base class
(also known as ``superclass'') version. In practice, constructors and
destructors are likely to want to do this, and it probably also makes
sense in the debug() method we showed previously.
To do this, add this to Employee.pm:
use Carp;
my $Debugging = 0;
sub debug {
my $self = shift;
confess "usage: thing->debug(level)" unless @_ == 1;
my $level = shift;
if (ref($self)) {
$self->{"_DEBUG"} = $level;
} else {
$Debugging = $level; # whole class
}
Person::debug($self, $Debugging); # don't really do this
}
As you see, we turn around and call the Person package's debug() function.
But this is far too fragile for good design. What if Person doesn't
have a debug() function, but is inheriting its debug() method
from elsewhere? It would have been slightly better to say
Person->debug($Debugging);
But even that's got too much hard-coded. It's somewhat better to say
$self->Person::debug($Debugging);
Which is a funny way to say to start looking for a debug() method up
in Person. This strategy is more often seen on overridden object methods
than on overridden class methods.
There is still something a bit off here. We've hard-coded our
superclass's name. This in particular is bad if you change which classes
you inherit from, or add others. Fortunately, the pseudoclass SUPER
comes to the rescue here.
$self->SUPER::debug($Debugging);
This way it starts looking in my class's @ISA. This only makes sense
from within a method call, though. Don't try to access anything
in SUPER:: from anywhere else, because it doesn't exist outside
an overridden method call.
Things are getting a bit complicated here. Have we done anything
we shouldn't? As before, one way to test whether we're designing
a decent class is via the empty subclass test. Since we already have
an Employee class that we're trying to check, we'd better get a new
empty subclass that can derive from Employee. Here's one:
package Boss;
use Employee; # :-)
@ISA = qw(Employee);
And here's the test program:
#!/usr/bin/perl -w
use strict;
use Boss;
Boss->debug(1);
my $boss = Boss->new();
$boss->fullname->title("Don");
$boss->fullname->surname("Pichon Alvarez");
$boss->fullname->christian("Federico Jesus");
$boss->fullname->nickname("Fred");
$boss->age(47);
$boss->peers("Frank", "Felipe", "Faust");
printf "%s is age %d.\n", $boss->fullname, $boss->age;
printf "His peers are: %s\n", join(", ", $boss->peers);
Running it, we see that we're still ok. If you'd like to dump out your
object in a nice format, somewhat like the way the 'x' command works in
the debugger, you could use the Data::Dumper module from CPAN this way:
use Data::Dumper;
print "Here's the boss:\n";
print Dumper($boss);
Which shows us something like this:
Here's the boss:
$VAR1 = bless( {
_CENSUS => \1,
FULLNAME => bless( {
TITLE => 'Don',
SURNAME => 'Pichon Alvarez',
NICK => 'Fred',
CHRISTIAN => 'Federico Jesus'
}, 'Fullname' ),
AGE => 47,
PEERS => [
'Frank',
'Felipe',
'Faust'
]
}, 'Boss' );
Hm.... something's missing there. What about the salary, start date,
and ID fields? Well, we never set them to anything, even undef, so they
don't show up in the hash's keys. The Employee class has no new() method
of its own, and the new() method in Person doesn't know about Employees.
(Nor should it: proper OO design dictates that a subclass be allowed to
know about its immediate superclass, but never vice-versa.) So let's
fix up Employee::new() this way:
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = $class->SUPER::new();
$self->{SALARY} = undef;
$self->{ID} = undef;
$self->{START_DATE} = undef;
bless ($self, $class); # reconsecrate
return $self;
}
Now if you dump out an Employee or Boss object, you'll find
that new fields show up there now.
Ok, at the risk of confusing beginners and annoying OO gurus, it's
time to confess that Perl's object system includes that controversial
notion known as multiple inheritance, or MI for short. All this means
is that rather than having just one parent class who in turn might
itself have a parent class, etc., that you can directly inherit from
two or more parents. It's true that some uses of MI can get you into
trouble, although hopefully not quite so much trouble with Perl as with
dubiously-OO languages like C++.
The way it works is actually pretty simple: just put more than one package
name in your @ISA array. When it comes time for Perl to go finding
methods for your object, it looks at each of these packages in order.
Well, kinda. It's actually a fully recursive, depth-first order.
Consider a bunch of @ISA arrays like this:
@First::ISA = qw( Alpha );
@Second::ISA = qw( Beta );
@Third::ISA = qw( First Second );
If you have an object of class Third:
my $ob = Third->new();
$ob->spin();
How do we find a spin() method (or a new() method for that matter)?
Because the search is depth-first, classes will be looked up
in the following order: Third, First, Alpha, Second, and Beta.
In practice, few class modules have been seen that actually
make use of MI. One nearly always chooses simple containership of
one class within another over MI. That's why our Person
object contained a Fullname object. That doesn't mean
it was one.
However, there is one particular area where MI in Perl is rampant:
borrowing another class's class methods. This is rather common,
especially with some bundled ``objectless'' classes,
like Exporter, DynaLoader, AutoLoader, and SelfLoader. These classes
do not provide constructors; they exist only so you may inherit their
class methods. (It's not entirely clear why inheritance was done
here rather than traditional module importation.)
For example, here is the POSIX module's @ISA:
package POSIX;
@ISA = qw(Exporter DynaLoader);
The POSIX module isn't really an object module, but then,
neither are Exporter or DynaLoader. They're just lending their
classes' behaviours to POSIX.
Why don't people use MI for object methods much? One reason is that
it can have complicated side-effects. For one thing, your inheritance
graph (no longer a tree) might converge back to the same base class.
Although Perl guards against recursive inheritance, merely having parents
who are related to each other via a common ancestor, incestuous though
it sounds, is not forbidden. What if in our Third class shown above we
wanted its new() method to also call both overridden constructors in its
two parent classes? The SUPER notation would only find the first one.
Also, what about if the Alpha and Beta classes both had a common ancestor,
like Nought? If you kept climbing up the inheritance tree calling
overridden methods, you'd end up calling Nought::new() twice,
which might well be a bad idea.
Wouldn't it be convenient if all objects were rooted at some ultimate
base class? That way you could give every object common methods without
having to go and add it to each and every @ISA. Well, it turns out that
you can. You don't see it, but Perl tacitly and irrevocably assumes
that there's an extra element at the end of @ISA: the class UNIVERSAL.
In version 5.003, there were no predefined methods there, but you could put
whatever you felt like into it.
However, as of version 5.004 (or some subversive releases, like 5.003_08),
UNIVERSAL has some methods in it already. These are builtin to your Perl
binary, so they don't take any extra time to load. Predefined methods
include isa(), can(), and VERSION(). isa() tells you whether an object or
class ``is'' anot | 
