1PERLTOOT(1) Perl Programmers Reference Guide PERLTOOT(1)
2
6 perltoot - Tom's object-oriented tutorial for perl
7
9 Object-oriented programming is a big seller these days. Some managers
10 would rather have objects than sliced bread. Why is that? What's so
11 special about an object? Just what is an object anyway?
12 An object is nothing but a way of tucking away complex behaviours into
14 a neat little easy-to-use bundle. (This is what professors call
15 abstraction.) Smart people who have nothing to do but sit around for
16 weeks on end figuring out really hard problems make these nifty objects
17 that even regular people can use. (This is what professors call soft‐
18 ware reuse.) Users (well, programmers) can play with this little bun‐
19 dle all they want, but they aren't to open it up and mess with the
20 insides. Just like an expensive piece of hardware, the contract says
21 that you void the warranty if you muck with the cover. So don't do
22 that.
23 The heart of objects is the class, a protected little private namespace
25 full of data and functions. A class is a set of related routines that
26 addresses some problem area. You can think of it as a user-defined
27 type. The Perl package mechanism, also used for more traditional mod‐
28 ules, is used for class modules as well. Objects "live" in a class,
29 meaning that they belong to some package.
30 More often than not, the class provides the user with little bundles.
32 These bundles are objects. They know whose class they belong to, and
33 how to behave. Users ask the class to do something, like "give me an
34 object." Or they can ask one of these objects to do something. Asking
35 a class to do something for you is calling a class method. Asking an
36 object to do something for you is calling an object method. Asking
37 either a class (usually) or an object (sometimes) to give you back an
38 object is calling a constructor, which is just a kind of method.
39 That's all well and good, but how is an object different from any other
41 Perl data type? Just what is an object really; that is, what's its
42 fundamental type? The answer to the first question is easy. An object
43 is different from any other data type in Perl in one and only one way:
44 you may dereference it using not merely string or numeric subscripts as
45 with simple arrays and hashes, but with named subroutine calls. In a
46 word, with methods.
47 The answer to the second question is that it's a reference, and not
49 just any reference, mind you, but one whose referent has been bless()ed
50 into a particular class (read: package). What kind of reference?
51 Well, the answer to that one is a bit less concrete. That's because in
52 Perl the designer of the class can employ any sort of reference they'd
53 like as the underlying intrinsic data type. It could be a scalar, an
54 array, or a hash reference. It could even be a code reference. But
55 because of its inherent flexibility, an object is usually a hash refer‐
56 ence.
57
59 Before you create a class, you need to decide what to name it. That's
60 because the class (package) name governs the name of the file used to
61 house it, just as with regular modules. Then, that class (package)
62 should provide one or more ways to generate objects. Finally, it
63 should provide mechanisms to allow users of its objects to indirectly
64 manipulate these objects from a distance.
65 For example, let's make a simple Person class module. It gets stored
67 in the file Person.pm. If it were called a Happy::Person class, it
68 would be stored in the file Happy/Person.pm, and its package would
69 become Happy::Person instead of just Person. (On a personal computer
70 not running Unix or Plan 9, but something like Mac OS or VMS, the
71 directory separator may be different, but the principle is the same.)
72 Do not assume any formal relationship between modules based on their
73 directory names. This is merely a grouping convenience, and has no
74 effect on inheritance, variable accessibility, or anything else.
75 For this module we aren't going to use Exporter, because we're a well-
77 behaved class module that doesn't export anything at all. In order to
78 manufacture objects, a class needs to have a constructor method. A
79 constructor gives you back not just a regular data type, but a brand-
80 new object in that class. This magic is taken care of by the bless()
81 function, whose sole purpose is to enable its referent to be used as an
82 object. Remember: being an object really means nothing more than that
83 methods may now be called against it.
84 While a constructor may be named anything you'd like, most Perl pro‐
86 grammers seem to like to call theirs new(). However, new() is not a
87 reserved word, and a class is under no obligation to supply such. Some
88 programmers have also been known to use a function with the same name
89 as the class as the constructor.
90 Object Representation
92 By far the most common mechanism used in Perl to represent a Pascal
94 record, a C struct, or a C++ class is an anonymous hash. That's
95 because a hash has an arbitrary number of data fields, each conve‐
96 niently accessed by an arbitrary name of your own devising.
97 If you were just doing a simple struct-like emulation, you would likely
99 go about it something like this:
100 $rec = {
102 name => "Jason",
103 age => 23,
104 peers => [ "Norbert", "Rhys", "Phineas"],
105 };
106 If you felt like it, you could add a bit of visual distinction by up-
108 casing the hash keys:
109 $rec = {
111 NAME => "Jason",
112 AGE => 23,
113 PEERS => [ "Norbert", "Rhys", "Phineas"],
114 };
115 And so you could get at "$rec->{NAME}" to find "Jason", or "@{
117 $rec->{PEERS} }" to get at "Norbert", "Rhys", and "Phineas". (Have you
118 ever noticed how many 23-year-old programmers seem to be named "Jason"
119 these days? :-)
120 This same model is often used for classes, although it is not consid‐
122 ered the pinnacle of programming propriety for folks from outside the
123 class to come waltzing into an object, brazenly accessing its data mem‐
124 bers directly. Generally speaking, an object should be considered an
125 opaque cookie that you use object methods to access. Visually, methods
126 look like you're dereffing a reference using a function name instead of
127 brackets or braces.
128 Class Interface
130 Some languages provide a formal syntactic interface to a class's meth‐
132 ods, but Perl does not. It relies on you to read the documentation of
133 each class. If you try to call an undefined method on an object, Perl
134 won't complain, but the program will trigger an exception while it's
135 running. Likewise, if you call a method expecting a prime number as
136 its argument with a non-prime one instead, you can't expect the com‐
137 piler to catch this. (Well, you can expect it all you like, but it's
138 not going to happen.)
139 Let's suppose you have a well-educated user of your Person class, some‐
141 one who has read the docs that explain the prescribed interface.
142 Here's how they might use the Person class:
143 use Person;
145 $him = Person->new();
147 $him->name("Jason");
148 $him->age(23);
149 $him->peers( "Norbert", "Rhys", "Phineas" );
150 push @All_Recs, $him; # save object in array for later
152 printf "%s is %d years old.\n", $him->name, $him->age;
154 print "His peers are: ", join(", ", $him->peers), "\n";
155 printf "Last rec's name is %s\n", $All_Recs[-1]->name;
157 As you can see, the user of the class doesn't know (or at least, has no
159 business paying attention to the fact) that the object has one particu‐
160 lar implementation or another. The interface to the class and its
161 objects is exclusively via methods, and that's all the user of the
162 class should ever play with.
163 Constructors and Instance Methods
165 Still, someone has to know what's in the object. And that someone is
167 the class. It implements methods that the programmer uses to access
168 the object. Here's how to implement the Person class using the stan‐
169 dard hash-ref-as-an-object idiom. We'll make a class method called
170 new() to act as the constructor, and three object methods called
171 name(), age(), and peers() to get at per-object data hidden away in our
172 anonymous hash.
173 package Person;
175 use strict;
176 ##################################################
178 ## the object constructor (simplistic version) ##
179 ##################################################
180 sub new {
181 my $self = {};
182 $self->{NAME} = undef;
183 $self->{AGE} = undef;
184 $self->{PEERS} = [];
185 bless($self); # but see below
186 return $self;
187 }
188 ##############################################
190 ## methods to access per-object data ##
191 ## ##
192 ## With args, they set the value. Without ##
193 ## any, they only retrieve it/them. ##
194 ##############################################
195 sub name {
197 my $self = shift;
198 if (@_) { $self->{NAME} = shift }
199 return $self->{NAME};
200 }
201 sub age {
203 my $self = shift;
204 if (@_) { $self->{AGE} = shift }
205 return $self->{AGE};
206 }
207 sub peers {
209 my $self = shift;
210 if (@_) { @{ $self->{PEERS} } = @_ }
211 return @{ $self->{PEERS} };
212 }
213 1; # so the require or use succeeds
215 We've created three methods to access an object's data, name(), age(),
217 and peers(). These are all substantially similar. If called with an
218 argument, they set the appropriate field; otherwise they return the
219 value held by that field, meaning the value of that hash key.
220 Planning for the Future: Better Constructors
222 Even though at this point you may not even know what it means, someday
224 you're going to worry about inheritance. (You can safely ignore this
225 for now and worry about it later if you'd like.) To ensure that this
226 all works out smoothly, you must use the double-argument form of
227 bless(). The second argument is the class into which the referent will
228 be blessed. By not assuming our own class as the default second argu‐
229 ment and instead using the class passed into us, we make our construc‐
230 tor inheritable.
231 sub new {
233 my $class = shift;
234 my $self = {};
235 $self->{NAME} = undef;
236 $self->{AGE} = undef;
237 $self->{PEERS} = [];
238 bless ($self, $class);
239 return $self;
240 }
241 That's about all there is for constructors. These methods bring
243 objects to life, returning neat little opaque bundles to the user to be
244 used in subsequent method calls.
245 Destructors
247 Every story has a beginning and an end. The beginning of the object's
249 story is its constructor, explicitly called when the object comes into
250 existence. But the ending of its story is the destructor, a method
251 implicitly called when an object leaves this life. Any per-object
252 clean-up code is placed in the destructor, which must (in Perl) be
253 called DESTROY.
254 If constructors can have arbitrary names, then why not destructors?
256 Because while a constructor is explicitly called, a destructor is not.
257 Destruction happens automatically via Perl's garbage collection (GC)
258 system, which is a quick but somewhat lazy reference-based GC system.
259 To know what to call, Perl insists that the destructor be named
260 DESTROY. Perl's notion of the right time to call a destructor is not
261 well-defined currently, which is why your destructors should not rely
262 on when they are called.
263 Why is DESTROY in all caps? Perl on occasion uses purely uppercase
265 function names as a convention to indicate that the function will be
266 automatically called by Perl in some way. Others that are called
267 implicitly include BEGIN, END, AUTOLOAD, plus all methods used by tied
268 objects, described in perltie.
269 In really good object-oriented programming languages, the user doesn't
271 care when the destructor is called. It just happens when it's supposed
272 to. In low-level languages without any GC at all, there's no way to
273 depend on this happening at the right time, so the programmer must
274 explicitly call the destructor to clean up memory and state, crossing
275 their fingers that it's the right time to do so. Unlike C++, an
276 object destructor is nearly never needed in Perl, and even when it is,
277 explicit invocation is uncalled for. In the case of our Person class,
278 we don't need a destructor because Perl takes care of simple matters
279 like memory deallocation.
280 The only situation where Perl's reference-based GC won't work is when
282 there's a circularity in the data structure, such as:
283 $this->{WHATEVER} = $this;
285 In that case, you must delete the self-reference manually if you expect
287 your program not to leak memory. While admittedly error-prone, this is
288 the best we can do right now. Nonetheless, rest assured that when your
289 program is finished, its objects' destructors are all duly called. So
290 you are guaranteed that an object eventually gets properly destroyed,
291 except in the unique case of a program that never exits. (If you're
292 running Perl embedded in another application, this full GC pass happens
293 a bit more frequently--whenever a thread shuts down.)
294 Other Object Methods
296 The methods we've talked about so far have either been constructors or
298 else simple "data methods", interfaces to data stored in the object.
299 These are a bit like an object's data members in the C++ world, except
300 that strangers don't access them as data. Instead, they should only
301 access the object's data indirectly via its methods. This is an impor‐
302 tant rule: in Perl, access to an object's data should only be made
303 through methods.
304 Perl doesn't impose restrictions on who gets to use which methods. The
306 public-versus-private distinction is by convention, not syntax. (Well,
307 unless you use the Alias module described below in "Data Members as
308 Variables".) Occasionally you'll see method names beginning or ending
309 with an underscore or two. This marking is a convention indicating
310 that the methods are private to that class alone and sometimes to its
311 closest acquaintances, its immediate subclasses. But this distinction
312 is not enforced by Perl itself. It's up to the programmer to behave.
313 There's no reason to limit methods to those that simply access data.
315 Methods can do anything at all. The key point is that they're invoked
316 against an object or a class. Let's say we'd like object methods that
317 do more than fetch or set one particular field.
318 sub exclaim {
320 my $self = shift;
321 return sprintf "Hi, I'm %s, age %d, working with %s",
322 $self->{NAME}, $self->{AGE}, join(", ", @{$self->{PEERS}});
323 }
324 Or maybe even one like this:
326 sub happy_birthday {
328 my $self = shift;
329 return ++$self->{AGE};
330 }
331 Some might argue that one should go at these this way:
333 sub exclaim {
335 my $self = shift;
336 return sprintf "Hi, I'm %s, age %d, working with %s",
337 $self->name, $self->age, join(", ", $self->peers);
338 }
339 sub happy_birthday {
341 my $self = shift;
342 return $self->age( $self->age() + 1 );
343 }
344 But since these methods are all executing in the class itself, this may
346 not be critical. There are tradeoffs to be made. Using direct hash
347 access is faster (about an order of magnitude faster, in fact), and
348 it's more convenient when you want to interpolate in strings. But
349 using methods (the external interface) internally shields not just the
350 users of your class but even you yourself from changes in your data
351 representation.
352
354 What about "class data", data items common to each object in a class?
355 What would you want that for? Well, in your Person class, you might
356 like to keep track of the total people alive. How do you implement
357 that?
358 You could make it a global variable called $Person::Census. But about
360 only reason you'd do that would be if you wanted people to be able to
361 get at your class data directly. They could just say $Person::Census
362 and play around with it. Maybe this is ok in your design scheme. You
363 might even conceivably want to make it an exported variable. To be
364 exportable, a variable must be a (package) global. If this were a tra‐
365 ditional module rather than an object-oriented one, you might do that.
366 While this approach is expected in most traditional modules, it's gen‐
368 erally considered rather poor form in most object modules. In an
369 object module, you should set up a protective veil to separate inter‐
370 face from implementation. So provide a class method to access class
371 data just as you provide object methods to access object data.
372 So, you could still keep $Census as a package global and rely upon oth‐
374 ers to honor the contract of the module and therefore not play around
375 with its implementation. You could even be supertricky and make $Cen‐
376 sus a tied object as described in perltie, thereby intercepting all
377 accesses.
378 But more often than not, you just want to make your class data a file-
380 scoped lexical. To do so, simply put this at the top of the file:
381 my $Census = 0;
383 Even though the scope of a my() normally expires when the block in
385 which it was declared is done (in this case the whole file being
386 required or used), Perl's deep binding of lexical variables guarantees
387 that the variable will not be deallocated, remaining accessible to
388 functions declared within that scope. This doesn't work with global
389 variables given temporary values via local(), though.
390 Irrespective of whether you leave $Census a package global or make it
392 instead a file-scoped lexical, you should make these changes to your
393 Person::new() constructor:
394 sub new {
396 my $class = shift;
397 my $self = {};
398 $Census++;
399 $self->{NAME} = undef;
400 $self->{AGE} = undef;
401 $self->{PEERS} = [];
402 bless ($self, $class);
403 return $self;
404 }
405 sub population {
407 return $Census;
408 }
409 Now that we've done this, we certainly do need a destructor so that
411 when Person is destroyed, the $Census goes down. Here's how this could
412 be done:
413 sub DESTROY { --$Census }
415 Notice how there's no memory to deallocate in the destructor? That's
417 something that Perl takes care of for you all by itself.
418 Alternatively, you could use the Class::Data::Inheritable module from
420 CPAN.
421 Accessing Class Data
423 It turns out that this is not really a good way to go about handling
425 class data. A good scalable rule is that you must never reference
426 class data directly from an object method. Otherwise you aren't build‐
427 ing a scalable, inheritable class. The object must be the rendezvous
428 point for all operations, especially from an object method. The glob‐
429 als (class data) would in some sense be in the "wrong" package in your
430 derived classes. In Perl, methods execute in the context of the class
431 they were defined in, not that of the object that triggered them.
432 Therefore, namespace visibility of package globals in methods is unre‐
433 lated to inheritance.
434 Got that? Maybe not. Ok, let's say that some other class "borrowed"
436 (well, inherited) the DESTROY method as it was defined above. When
437 those objects are destroyed, the original $Census variable will be
438 altered, not the one in the new class's package namespace. Perhaps
439 this is what you want, but probably it isn't.
440 Here's how to fix this. We'll store a reference to the data in the
442 value accessed by the hash key "_CENSUS". Why the underscore? Well,
443 mostly because an initial underscore already conveys strong feelings of
444 magicalness to a C programmer. It's really just a mnemonic device to
445 remind ourselves that this field is special and not to be used as a
446 public data member in the same way that NAME, AGE, and PEERS are.
447 (Because we've been developing this code under the strict pragma, prior
448 to perl version 5.004 we'll have to quote the field name.)
449 sub new {
451 my $class = shift;
452 my $self = {};
453 $self->{NAME} = undef;
454 $self->{AGE} = undef;
455 $self->{PEERS} = [];
456 # "private" data
457 $self->{"_CENSUS"} = \$Census;
458 bless ($self, $class);
459 ++ ${ $self->{"_CENSUS"} };
460 return $self;
461 }
462 sub population {
464 my $self = shift;
465 if (ref $self) {
466 return ${ $self->{"_CENSUS"} };
467 } else {
468 return $Census;
469 }
470 }
471 sub DESTROY {
473 my $self = shift;
474 -- ${ $self->{"_CENSUS"} };
475 }
476 Debugging Methods
478 It's common for a class to have a debugging mechanism. For example,
480 you might want to see when objects are created or destroyed. To do
481 that, add a debugging variable as a file-scoped lexical. For this,
482 we'll pull in the standard Carp module to emit our warnings and fatal
483 messages. That way messages will come out with the caller's filename
484 and line number instead of our own; if we wanted them to be from our
485 own perspective, we'd just use die() and warn() directly instead of
486 croak() and carp() respectively.
487 use Carp;
489 my $Debugging = 0;
490 Now add a new class method to access the variable.
492 sub debug {
494 my $class = shift;
495 if (ref $class) { confess "Class method called as object method" }
496 unless (@_ == 1) { confess "usage: CLASSNAME->debug(level)" }
497 $Debugging = shift;
498 }
499 Now fix up DESTROY to murmur a bit as the moribund object expires:
501 sub DESTROY {
503 my $self = shift;
504 if ($Debugging) { carp "Destroying $self " . $self->name }
505 -- ${ $self->{"_CENSUS"} };
506 }
507 One could conceivably make a per-object debug state. That way you
509 could call both of these:
510 Person->debug(1); # entire class
512 $him->debug(1); # just this object
513 To do so, we need our debugging method to be a "bimodal" one, one that
515 works on both classes and objects. Therefore, adjust the debug() and
516 DESTROY methods as follows:
517 sub debug {
519 my $self = shift;
520 confess "usage: thing->debug(level)" unless @_ == 1;
521 my $level = shift;
522 if (ref($self)) {
523 $self->{"_DEBUG"} = $level; # just myself
524 } else {
525 $Debugging = $level; # whole class
526 }
527 }
528 sub DESTROY {
530 my $self = shift;
531 if ($Debugging ⎪⎪ $self->{"_DEBUG"}) {
532 carp "Destroying $self " . $self->name;
533 }
534 -- ${ $self->{"_CENSUS"} };
535 }
536 What happens if a derived class (which we'll call Employee) inherits
538 methods from this Person base class? Then "Employee->debug()", when
539 called as a class method, manipulates $Person::Debugging not
540 $Employee::Debugging.
541 Class Destructors
543 The object destructor handles the death of each distinct object. But
545 sometimes you want a bit of cleanup when the entire class is shut down,
546 which currently only happens when the program exits. To make such a
547 class destructor, create a function in that class's package named END.
548 This works just like the END function in traditional modules, meaning
549 that it gets called whenever your program exits unless it execs or dies
550 of an uncaught signal. For example,
551 sub END {
553 if ($Debugging) {
554 print "All persons are going away now.\n";
555 }
556 }
557 When the program exits, all the class destructors (END functions) are
559 be called in the opposite order that they were loaded in (LIFO order).
560 Documenting the Interface
562 And there you have it: we've just shown you the implementation of this
564 Person class. Its interface would be its documentation. Usually this
565 means putting it in pod ("plain old documentation") format right there
566 in the same file. In our Person example, we would place the following
567 docs anywhere in the Person.pm file. Even though it looks mostly like
568 code, it's not. It's embedded documentation such as would be used by
569 the pod2man, pod2html, or pod2text programs. The Perl compiler ignores
570 pods entirely, just as the translators ignore code. Here's an example
571 of some pods describing the informal interface:
572 =head1 NAME
574 Person - class to implement people
576 =head1 SYNOPSIS
578 use Person;
580 #################
582 # class methods #
583 #################
584 $ob = Person->new;
585 $count = Person->population;
586 #######################
588 # object data methods #
589 #######################
590 ### get versions ###
592 $who = $ob->name;
593 $years = $ob->age;
594 @pals = $ob->peers;
595 ### set versions ###
597 $ob->name("Jason");
598 $ob->age(23);
599 $ob->peers( "Norbert", "Rhys", "Phineas" );
600 ########################
602 # other object methods #
603 ########################
604 $phrase = $ob->exclaim;
606 $ob->happy_birthday;
607 =head1 DESCRIPTION
609 The Person class implements dah dee dah dee dah....
611 That's all there is to the matter of interface versus implementation.
613 A programmer who opens up the module and plays around with all the pri‐
614 vate little shiny bits that were safely locked up behind the interface
615 contract has voided the warranty, and you shouldn't worry about their
616 fate.
617
619 Suppose you later want to change the class to implement better names.
620 Perhaps you'd like to support both given names (called Christian names,
621 irrespective of one's religion) and family names (called surnames),
622 plus nicknames and titles. If users of your Person class have been
623 properly accessing it through its documented interface, then you can
624 easily change the underlying implementation. If they haven't, then
625 they lose and it's their fault for breaking the contract and voiding
626 their warranty.
627 To do this, we'll make another class, this one called Fullname. What's
629 the Fullname class look like? To answer that question, you have to
630 first figure out how you want to use it. How about we use it this way:
631 $him = Person->new();
633 $him->fullname->title("St");
634 $him->fullname->christian("Thomas");
635 $him->fullname->surname("Aquinas");
636 $him->fullname->nickname("Tommy");
637 printf "His normal name is %s\n", $him->name;
638 printf "But his real name is %s\n", $him->fullname->as_string;
639 Ok. To do this, we'll change Person::new() so that it supports a full
641 name field this way:
642 sub new {
644 my $class = shift;
645 my $self = {};
646 $self->{FULLNAME} = Fullname->new();
647 $self->{AGE} = undef;
648 $self->{PEERS} = [];
649 $self->{"_CENSUS"} = \$Census;
650 bless ($self, $class);
651 ++ ${ $self->{"_CENSUS"} };
652 return $self;
653 }
654 sub fullname {
656 my $self = shift;
657 return $self->{FULLNAME};
658 }
659 Then to support old code, define Person::name() this way:
661 sub name {
663 my $self = shift;
664 return $self->{FULLNAME}->nickname(@_)
665 ⎪⎪ $self->{FULLNAME}->christian(@_);
666 }
667 Here's the Fullname class. We'll use the same technique of using a
669 hash reference to hold data fields, and methods by the appropriate name
670 to access them:
671 package Fullname;
673 use strict;
674 sub new {
676 my $class = shift;
677 my $self = {
678 TITLE => undef,
679 CHRISTIAN => undef,
680 SURNAME => undef,
681 NICK => undef,
682 };
683 bless ($self, $class);
684 return $self;
685 }
686 sub christian {
688 my $self = shift;
689 if (@_) { $self->{CHRISTIAN} = shift }
690 return $self->{CHRISTIAN};
691 }
692 sub surname {
694 my $self = shift;
695 if (@_) { $self->{SURNAME} = shift }
696 return $self->{SURNAME};
697 }
698 sub nickname {
700 my $self = shift;
701 if (@_) { $self->{NICK} = shift }
702 return $self->{NICK};
703 }
704 sub title {
706 my $self = shift;
707 if (@_) { $self->{TITLE} = shift }
708 return $self->{TITLE};
709 }
710 sub as_string {
712 my $self = shift;
713 my $name = join(" ", @$self{'CHRISTIAN', 'SURNAME'});
714 if ($self->{TITLE}) {
715 $name = $self->{TITLE} . " " . $name;
716 }
717 return $name;
718 }
719 1;
721 Finally, here's the test program:
723 #!/usr/bin/perl -w
725 use strict;
726 use Person;
727 sub END { show_census() }
728 sub show_census () {
730 printf "Current population: %d\n", Person->population;
731 }
732 Person->debug(1);
734 show_census();
736 my $him = Person->new();
738 $him->fullname->christian("Thomas");
740 $him->fullname->surname("Aquinas");
741 $him->fullname->nickname("Tommy");
742 $him->fullname->title("St");
743 $him->age(1);
744 printf "%s is really %s.\n", $him->name, $him->fullname->as_string;
746 printf "%s's age: %d.\n", $him->name, $him->age;
747 $him->happy_birthday;
748 printf "%s's age: %d.\n", $him->name, $him->age;
749 show_census();
751
753 Object-oriented programming systems all support some notion of inheri‐
754 tance. Inheritance means allowing one class to piggy-back on top of
755 another one so you don't have to write the same code again and again.
756 It's about software reuse, and therefore related to Laziness, the prin‐
757 cipal virtue of a programmer. (The import/export mechanisms in tradi‐
758 tional modules are also a form of code reuse, but a simpler one than
759 the true inheritance that you find in object modules.)
760 Sometimes the syntax of inheritance is built into the core of the lan‐
762 guage, and sometimes it's not. Perl has no special syntax for specify‐
763 ing the class (or classes) to inherit from. Instead, it's all strictly
764 in the semantics. Each package can have a variable called @ISA, which
765 governs (method) inheritance. If you try to call a method on an object
766 or class, and that method is not found in that object's package, Perl
767 then looks to @ISA for other packages to go looking through in search
768 of the missing method.
769 Like the special per-package variables recognized by Exporter (such as
771 @EXPORT, @EXPORT_OK, @EXPORT_FAIL, %EXPORT_TAGS, and $VERSION), the
772 @ISA array must be a package-scoped global and not a file-scoped lexi‐
773 cal created via my(). Most classes have just one item in their @ISA
774 array. In this case, we have what's called "single inheritance", or SI
775 for short.
776 Consider this class:
778 package Employee;
780 use Person;
781 @ISA = ("Person");
782 1;
783 Not a lot to it, eh? All it's doing so far is loading in another class
785 and stating that this one will inherit methods from that other class if
786 need be. We have given it none of its own methods. We rely upon an
787 Employee to behave just like a Person.
788 Setting up an empty class like this is called the "empty subclass
790 test"; that is, making a derived class that does nothing but inherit
791 from a base class. If the original base class has been designed prop‐
792 erly, then the new derived class can be used as a drop-in replacement
793 for the old one. This means you should be able to write a program like
794 this:
795 use Employee;
797 my $empl = Employee->new();
798 $empl->name("Jason");
799 $empl->age(23);
800 printf "%s is age %d.\n", $empl->name, $empl->age;
801 By proper design, we mean always using the two-argument form of
803 bless(), avoiding direct access of global data, and not exporting any‐
804 thing. If you look back at the Person::new() function we defined
805 above, we were careful to do that. There's a bit of package data used
806 in the constructor, but the reference to this is stored on the object
807 itself and all other methods access package data via that reference, so
808 we should be ok.
809 What do we mean by the Person::new() function -- isn't that actually a
811 method? Well, in principle, yes. A method is just a function that
812 expects as its first argument a class name (package) or object (blessed
813 reference). Person::new() is the function that both the "Per‐
814 son->new()" method and the "Employee->new()" method end up calling.
815 Understand that while a method call looks a lot like a function call,
816 they aren't really quite the same, and if you treat them as the same,
817 you'll very soon be left with nothing but broken programs. First, the
818 actual underlying calling conventions are different: method calls get
819 an extra argument. Second, function calls don't do inheritance, but
820 methods do.
821 Method Call Resulting Function Call
823 ----------- ------------------------
824 Person->new() Person::new("Person")
825 Employee->new() Person::new("Employee")
826 So don't use function calls when you mean to call a method.
828 If an employee is just a Person, that's not all too very interesting.
830 So let's add some other methods. We'll give our employee data fields
831 to access their salary, their employee ID, and their start date.
832 If you're getting a little tired of creating all these nearly identical
834 methods just to get at the object's data, do not despair. Later, we'll
835 describe several different convenience mechanisms for shortening this
836 up. Meanwhile, here's the straight-forward way:
837 sub salary {
839 my $self = shift;
840 if (@_) { $self->{SALARY} = shift }
841 return $self->{SALARY};
842 }
843 sub id_number {
845 my $self = shift;
846 if (@_) { $self->{ID} = shift }
847 return $self->{ID};
848 }
849 sub start_date {
851 my $self = shift;
852 if (@_) { $self->{START_DATE} = shift }
853 return $self->{START_DATE};
854 }
855 Overridden Methods
857 What happens when both a derived class and its base class have the same
859 method defined? Well, then you get the derived class's version of that
860 method. For example, let's say that we want the peers() method called
861 on an employee to act a bit differently. Instead of just returning the
862 list of peer names, let's return slightly different strings. So doing
863 this:
864 $empl->peers("Peter", "Paul", "Mary");
866 printf "His peers are: %s\n", join(", ", $empl->peers);
867 will produce:
869 His peers are: PEON=PETER, PEON=PAUL, PEON=MARY
871 To do this, merely add this definition into the Employee.pm file:
873 sub peers {
875 my $self = shift;
876 if (@_) { @{ $self->{PEERS} } = @_ }
877 return map { "PEON=\U$_" } @{ $self->{PEERS} };
878 }
879 There, we've just demonstrated the high-falutin' concept known in cer‐
881 tain circles as polymorphism. We've taken on the form and behaviour of
882 an existing object, and then we've altered it to suit our own purposes.
883 This is a form of Laziness. (Getting polymorphed is also what happens
884 when the wizard decides you'd look better as a frog.)
885 Every now and then you'll want to have a method call trigger both its
887 derived class (also known as "subclass") version as well as its base
888 class (also known as "superclass") version. In practice, constructors
889 and destructors are likely to want to do this, and it probably also
890 makes sense in the debug() method we showed previously.
891 To do this, add this to Employee.pm:
893 use Carp;
895 my $Debugging = 0;
896 sub debug {
898 my $self = shift;
899 confess "usage: thing->debug(level)" unless @_ == 1;
900 my $level = shift;
901 if (ref($self)) {
902 $self->{"_DEBUG"} = $level;
903 } else {
904 $Debugging = $level; # whole class
905 }
906 Person::debug($self, $Debugging); # don't really do this
907 }
908 As you see, we turn around and call the Person package's debug() func‐
910 tion. But this is far too fragile for good design. What if Person
911 doesn't have a debug() function, but is inheriting its debug() method
912 from elsewhere? It would have been slightly better to say
913 Person->debug($Debugging);
915 But even that's got too much hard-coded. It's somewhat better to say
917 $self->Person::debug($Debugging);
919 Which is a funny way to say to start looking for a debug() method up in
921 Person. This strategy is more often seen on overridden object methods
922 than on overridden class methods.
923 There is still something a bit off here. We've hard-coded our super‐
925 class's name. This in particular is bad if you change which classes
926 you inherit from, or add others. Fortunately, the pseudoclass SUPER
927 comes to the rescue here.
928 $self->SUPER::debug($Debugging);
930 This way it starts looking in my class's @ISA. This only makes sense
932 from within a method call, though. Don't try to access anything in
933 SUPER:: from anywhere else, because it doesn't exist outside an over‐
934 ridden method call. Note that "SUPER" refers to the superclass of the
935 current package, not to the superclass of $self.
936 Things are getting a bit complicated here. Have we done anything we
938 shouldn't? As before, one way to test whether we're designing a decent
939 class is via the empty subclass test. Since we already have an
940 Employee class that we're trying to check, we'd better get a new empty
941 subclass that can derive from Employee. Here's one:
942 package Boss;
944 use Employee; # :-)
945 @ISA = qw(Employee);
946 And here's the test program:
948 #!/usr/bin/perl -w
950 use strict;
951 use Boss;
952 Boss->debug(1);
953 my $boss = Boss->new();
955 $boss->fullname->title("Don");
957 $boss->fullname->surname("Pichon Alvarez");
958 $boss->fullname->christian("Federico Jesus");
959 $boss->fullname->nickname("Fred");
960 $boss->age(47);
962 $boss->peers("Frank", "Felipe", "Faust");
963 printf "%s is age %d.\n", $boss->fullname->as_string, $boss->age;
965 printf "His peers are: %s\n", join(", ", $boss->peers);
966 Running it, we see that we're still ok. If you'd like to dump out your
968 object in a nice format, somewhat like the way the 'x' command works in
969 the debugger, you could use the Data::Dumper module from CPAN this way:
970 use Data::Dumper;
972 print "Here's the boss:\n";
973 print Dumper($boss);
974 Which shows us something like this:
976 Here's the boss:
978 $VAR1 = bless( {
979 _CENSUS => \1,
980 FULLNAME => bless( {
981 TITLE => 'Don',
982 SURNAME => 'Pichon Alvarez',
983 NICK => 'Fred',
984 CHRISTIAN => 'Federico Jesus'
985 }, 'Fullname' ),
986 AGE => 47,
987 PEERS => [
988 'Frank',
989 'Felipe',
990 'Faust'
991 ]
992 }, 'Boss' );
993 Hm.... something's missing there. What about the salary, start date,
995 and ID fields? Well, we never set them to anything, even undef, so
996 they don't show up in the hash's keys. The Employee class has no new()
997 method of its own, and the new() method in Person doesn't know about
998 Employees. (Nor should it: proper OO design dictates that a subclass
999 be allowed to know about its immediate superclass, but never
1000 vice-versa.) So let's fix up Employee::new() this way:
1001 sub new {
1003 my $class = shift;
1004 my $self = $class->SUPER::new();
1005 $self->{SALARY} = undef;
1006 $self->{ID} = undef;
1007 $self->{START_DATE} = undef;
1008 bless ($self, $class); # reconsecrate
1009 return $self;
1010 }
1011 Now if you dump out an Employee or Boss object, you'll find that new
1013 fields show up there now.
1014 Multiple Inheritance
1016 Ok, at the risk of confusing beginners and annoying OO gurus, it's time
1018 to confess that Perl's object system includes that controversial notion
1019 known as multiple inheritance, or MI for short. All this means is that
1020 rather than having just one parent class who in turn might itself have
1021 a parent class, etc., that you can directly inherit from two or more
1022 parents. It's true that some uses of MI can get you into trouble,
1023 although hopefully not quite so much trouble with Perl as with dubi‐
1024 ously-OO languages like C++.
1025 The way it works is actually pretty simple: just put more than one
1027 package name in your @ISA array. When it comes time for Perl to go
1028 finding methods for your object, it looks at each of these packages in
1029 order. Well, kinda. It's actually a fully recursive, depth-first
1030 order. Consider a bunch of @ISA arrays like this:
1031 @First::ISA = qw( Alpha );
1033 @Second::ISA = qw( Beta );
1034 @Third::ISA = qw( First Second );
1035 If you have an object of class Third:
1037 my $ob = Third->new();
1039 $ob->spin();
1040 How do we find a spin() method (or a new() method for that matter)?
1042 Because the search is depth-first, classes will be looked up in the
1043 following order: Third, First, Alpha, Second, and Beta.
1044 In practice, few class modules have been seen that actually make use of
1046 MI. One nearly always chooses simple containership of one class within
1047 another over MI. That's why our Person object contained a Fullname
1048 object. That doesn't mean it was one.
1049 However, there is one particular area where MI in Perl is rampant: bor‐
1051 rowing another class's class methods. This is rather common, espe‐
1052 cially with some bundled "objectless" classes, like Exporter,
1053 DynaLoader, AutoLoader, and SelfLoader. These classes do not provide
1054 constructors; they exist only so you may inherit their class methods.
1055 (It's not entirely clear why inheritance was done here rather than tra‐
1056 ditional module importation.)
1057 For example, here is the POSIX module's @ISA:
1059 package POSIX;
1061 @ISA = qw(Exporter DynaLoader);
1062 The POSIX module isn't really an object module, but then, neither are
1064 Exporter or DynaLoader. They're just lending their classes' behaviours
1065 to POSIX.
1066 Why don't people use MI for object methods much? One reason is that it
1068 can have complicated side-effects. For one thing, your inheritance
1069 graph (no longer a tree) might converge back to the same base class.
1070 Although Perl guards against recursive inheritance, merely having par‐
1071 ents who are related to each other via a common ancestor, incestuous
1072 though it sounds, is not forbidden. What if in our Third class shown
1073 above we wanted its new() method to also call both overridden construc‐
1074 tors in its two parent classes? The SUPER notation would only find the
1075 first one. Also, what about if the Alpha and Beta classes both had a
1076 common ancestor, like Nought? If you kept climbing up the inheritance
1077 tree calling overridden methods, you'd end up calling Nought::new()
1078 twice, which might well be a bad idea.
1079 UNIVERSAL: The Root of All Objects
1081 Wouldn't it be convenient if all objects were rooted at some ultimate
1083 base class? That way you could give every object common methods with‐
1084 out having to go and add it to each and every @ISA. Well, it turns out
1085 that you can. You don't see it, but Perl tacitly and irrevocably
1086 assumes that there's an extra element at the end of @ISA: the class
1087 UNIVERSAL. In version 5.003, there were no predefined methods there,
1088 but you could put whatever you felt like into it.
1089 However, as of version 5.004 (or some subversive releases, like
1091 5.003_08), UNIVERSAL has some methods in it already. These are builtin
1092 to your Perl binary, so they don't take any extra time to load. Prede‐
1093 fined methods include isa(), can(), and VERSION(). isa() tells you
1094 whether an object or class "is" another one without having to traverse
1095 the hierarchy yourself:
1096 $has_io = $fd->isa("IO::Handle");
1098 $itza_handle = IO::Socket->isa("IO::Handle");
1099 The can() method, called against that object or class, reports back
1101 whether its string argument is a callable method name in that class.
1102 In fact, it gives you back a function reference to that method:
1103 $his_print_method = $obj->can('as_string');
1105 Finally, the VERSION method checks whether the class (or the object's
1107 class) has a package global called $VERSION that's high enough, as in:
1108 Some_Module->VERSION(3.0);
1110 $his_vers = $ob->VERSION();
1111 However, we don't usually call VERSION ourselves. (Remember that an
1113 all uppercase function name is a Perl convention that indicates that
1114 the function will be automatically used by Perl in some way.) In this
1115 case, it happens when you say
1116 use Some_Module 3.0;
1118 If you wanted to add version checking to your Person class explained
1120 above, just add this to Person.pm:
1121 our $VERSION = '1.1';
1123 and then in Employee.pm you can say
1125 use Person 1.1;
1127 And it would make sure that you have at least that version number or
1129 higher available. This is not the same as loading in that exact ver‐
1130 sion number. No mechanism currently exists for concurrent installation
1131 of multiple versions of a module. Lamentably.
1132
1134 Nothing requires objects to be implemented as hash references. An
1135 object can be any sort of reference so long as its referent has been
1136 suitably blessed. That means scalar, array, and code references are
1137 also fair game.
1138 A scalar would work if the object has only one datum to hold. An array
1140 would work for most cases, but makes inheritance a bit dodgy because
1141 you have to invent new indices for the derived classes.
1142 Arrays as Objects
1144 If the user of your class honors the contract and sticks to the adver‐
1146 tised interface, then you can change its underlying interface if you
1147 feel like it. Here's another implementation that conforms to the same
1148 interface specification. This time we'll use an array reference
1149 instead of a hash reference to represent the object.
1150 package Person;
1152 use strict;
1153 my($NAME, $AGE, $PEERS) = ( 0 .. 2 );
1155 ############################################
1157 ## the object constructor (array version) ##
1158 ############################################
1159 sub new {
1160 my $self = [];
1161 $self->[$NAME] = undef; # this is unnecessary
1162 $self->[$AGE] = undef; # as is this
1163 $self->[$PEERS] = []; # but this isn't, really
1164 bless($self);
1165 return $self;
1166 }
1167 sub name {
1169 my $self = shift;
1170 if (@_) { $self->[$NAME] = shift }
1171 return $self->[$NAME];
1172 }
1173 sub age {
1175 my $self = shift;
1176 if (@_) { $self->[$AGE] = shift }
1177 return $self->[$AGE];
1178 }
1179 sub peers {
1181 my $self = shift;
1182 if (@_) { @{ $self->[$PEERS] } = @_ }
1183 return @{ $self->[$PEERS] };
1184 }
1185 1; # so the require or use succeeds
1187 You might guess that the array access would be a lot faster than the
1189 hash access, but they're actually comparable. The array is a little
1190 bit faster, but not more than ten or fifteen percent, even when you
1191 replace the variables above like $AGE with literal numbers, like 1. A
1192 bigger difference between the two approaches can be found in memory
1193 use. A hash representation takes up more memory than an array repre‐
1194 sentation because you have to allocate memory for the keys as well as
1195 for the values. However, it really isn't that bad, especially since as
1196 of version 5.004, memory is only allocated once for a given hash key,
1197 no matter how many hashes have that key. It's expected that sometime
1198 in the future, even these differences will fade into obscurity as more
1199 efficient underlying representations are devised.
1200 Still, the tiny edge in speed (and somewhat larger one in memory) is
1202 enough to make some programmers choose an array representation for sim‐
1203 ple classes. There's still a little problem with scalability, though,
1204 because later in life when you feel like creating subclasses, you'll
1205 find that hashes just work out better.
1206 Closures as Objects
1208 Using a code reference to represent an object offers some fascinating
1210 possibilities. We can create a new anonymous function (closure) who
1211 alone in all the world can see the object's data. This is because we
1212 put the data into an anonymous hash that's lexically visible only to
1213 the closure we create, bless, and return as the object. This object's
1214 methods turn around and call the closure as a regular subroutine call,
1215 passing it the field we want to affect. (Yes, the double-function call
1216 is slow, but if you wanted fast, you wouldn't be using objects at all,
1217 eh? :-)
1218 Use would be similar to before:
1220 use Person;
1222 $him = Person->new();
1223 $him->name("Jason");
1224 $him->age(23);
1225 $him->peers( [ "Norbert", "Rhys", "Phineas" ] );
1226 printf "%s is %d years old.\n", $him->name, $him->age;
1227 print "His peers are: ", join(", ", @{$him->peers}), "\n";
1228 but the implementation would be radically, perhaps even sublimely dif‐
1230 ferent:
1231 package Person;
1233 sub new {
1235 my $class = shift;
1236 my $self = {
1237 NAME => undef,
1238 AGE => undef,
1239 PEERS => [],
1240 };
1241 my $closure = sub {
1242 my $field = shift;
1243 if (@_) { $self->{$field} = shift }
1244 return $self->{$field};
1245 };
1246 bless($closure, $class);
1247 return $closure;
1248 }
1249 sub name { &{ $_[0] }("NAME", @_[ 1 .. $#_ ] ) }
1251 sub age { &{ $_[0] }("AGE", @_[ 1 .. $#_ ] ) }
1252 sub peers { &{ $_[0] }("PEERS", @_[ 1 .. $#_ ] ) }
1253 1;
1255 Because this object is hidden behind a code reference, it's probably a
1257 bit mysterious to those whose background is more firmly rooted in stan‐
1258 dard procedural or object-based programming languages than in func‐
1259 tional programming languages whence closures derive. The object cre‐
1260 ated and returned by the new() method is itself not a data reference as
1261 we've seen before. It's an anonymous code reference that has within it
1262 access to a specific version (lexical binding and instantiation) of the
1263 object's data, which are stored in the private variable $self.
1264 Although this is the same function each time, it contains a different
1265 version of $self.
1266 When a method like "$him->name("Jason")" is called, its implicit zeroth
1268 argument is the invoking object--just as it is with all method calls.
1269 But in this case, it's our code reference (something like a function
1270 pointer in C++, but with deep binding of lexical variables). There's
1271 not a lot to be done with a code reference beyond calling it, so that's
1272 just what we do when we say "&{$_[0]}". This is just a regular func‐
1273 tion call, not a method call. The initial argument is the string
1274 "NAME", and any remaining arguments are whatever had been passed to the
1275 method itself.
1276 Once we're executing inside the closure that had been created in new(),
1278 the $self hash reference suddenly becomes visible. The closure grabs
1279 its first argument ("NAME" in this case because that's what the name()
1280 method passed it), and uses that string to subscript into the private
1281 hash hidden in its unique version of $self.
1282 Nothing under the sun will allow anyone outside the executing method to
1284 be able to get at this hidden data. Well, nearly nothing. You could
1285 single step through the program using the debugger and find out the
1286 pieces while you're in the method, but everyone else is out of luck.
1287 There, if that doesn't excite the Scheme folks, then I just don't know
1289 what will. Translation of this technique into C++, Java, or any other
1290 braindead-static language is left as a futile exercise for aficionados
1291 of those camps.
1292 You could even add a bit of nosiness via the caller() function and make
1294 the closure refuse to operate unless called via its own package. This
1295 would no doubt satisfy certain fastidious concerns of programming
1296 police and related puritans.
1297 If you were wondering when Hubris, the third principle virtue of a pro‐
1299 grammer, would come into play, here you have it. (More seriously,
1300 Hubris is just the pride in craftsmanship that comes from having writ‐
1301 ten a sound bit of well-designed code.)
1302
1304 Autoloading is a way to intercept calls to undefined methods. An
1305 autoload routine may choose to create a new function on the fly, either
1306 loaded from disk or perhaps just eval()ed right there. This define-on-
1307 the-fly strategy is why it's called autoloading.
1308 But that's only one possible approach. Another one is to just have the
1310 autoloaded method itself directly provide the requested service. When
1311 used in this way, you may think of autoloaded methods as "proxy" meth‐
1312 ods.
1313 When Perl tries to call an undefined function in a particular package
1315 and that function is not defined, it looks for a function in that same
1316 package called AUTOLOAD. If one exists, it's called with the same
1317 arguments as the original function would have had. The fully-qualified
1318 name of the function is stored in that package's global variable
1319 $AUTOLOAD. Once called, the function can do anything it would like,
1320 including defining a new function by the right name, and then doing a
1321 really fancy kind of "goto" right to it, erasing itself from the call
1322 stack.
1323 What does this have to do with objects? After all, we keep talking
1325 about functions, not methods. Well, since a method is just a function
1326 with an extra argument and some fancier semantics about where it's
1327 found, we can use autoloading for methods, too. Perl doesn't start
1328 looking for an AUTOLOAD method until it has exhausted the recursive
1329 hunt up through @ISA, though. Some programmers have even been known to
1330 define a UNIVERSAL::AUTOLOAD method to trap unresolved method calls to
1331 any kind of object.
1332 Autoloaded Data Methods
1334 You probably began to get a little suspicious about the duplicated code
1336 way back earlier when we first showed you the Person class, and then
1337 later the Employee class. Each method used to access the hash fields
1338 looked virtually identical. This should have tickled that great pro‐
1339 gramming virtue, Impatience, but for the time, we let Laziness win out,
1340 and so did nothing. Proxy methods can cure this.
1341 Instead of writing a new function every time we want a new data field,
1343 we'll use the autoload mechanism to generate (actually, mimic) methods
1344 on the fly. To verify that we're accessing a valid member, we will
1345 check against an "_permitted" (pronounced "under-permitted") field,
1346 which is a reference to a file-scoped lexical (like a C file static)
1347 hash of permitted fields in this record called %fields. Why the under‐
1348 score? For the same reason as the _CENSUS field we once used: as a
1349 marker that means "for internal use only".
1350 Here's what the module initialization code and class constructor will
1352 look like when taking this approach:
1353 package Person;
1355 use Carp;
1356 our $AUTOLOAD; # it's a package global
1357 my %fields = (
1359 name => undef,
1360 age => undef,
1361 peers => undef,
1362 );
1363 sub new {
1365 my $class = shift;
1366 my $self = {
1367 _permitted => \%fields,
1368 %fields,
1369 };
1370 bless $self, $class;
1371 return $self;
1372 }
1373 If we wanted our record to have default values, we could fill those in
1375 where current we have "undef" in the %fields hash.
1376 Notice how we saved a reference to our class data on the object itself?
1378 Remember that it's important to access class data through the object
1379 itself instead of having any method reference %fields directly, or else
1380 you won't have a decent inheritance.
1381 The real magic, though, is going to reside in our proxy method, which
1383 will handle all calls to undefined methods for objects of class Person
1384 (or subclasses of Person). It has to be called AUTOLOAD. Again, it's
1385 all caps because it's called for us implicitly by Perl itself, not by a
1386 user directly.
1387 sub AUTOLOAD {
1389 my $self = shift;
1390 my $type = ref($self)
1391 or croak "$self is not an object";
1392 my $name = $AUTOLOAD;
1394 $name =~ s/.*://; # strip fully-qualified portion
1395 unless (exists $self->{_permitted}->{$name} ) {
1397 croak "Can't access `$name' field in class $type";
1398 }
1399 if (@_) {
1401 return $self->{$name} = shift;
1402 } else {
1403 return $self->{$name};
1404 }
1405 }
1406 Pretty nifty, eh? All we have to do to add new data fields is modify
1408 %fields. No new functions need be written.
1409 I could have avoided the "_permitted" field entirely, but I wanted to
1411 demonstrate how to store a reference to class data on the object so you
1412 wouldn't have to access that class data directly from an object method.
1413 Inherited Autoloaded Data Methods
1415 But what about inheritance? Can we define our Employee class simi‐
1417 larly? Yes, so long as we're careful enough.
1418 Here's how to be careful:
1420 package Employee;
1422 use Person;
1423 use strict;
1424 our @ISA = qw(Person);
1425 my %fields = (
1427 id => undef,
1428 salary => undef,
1429 );
1430 sub new {
1432 my $class = shift;
1433 my $self = $class->SUPER::new();
1434 my($element);
1435 foreach $element (keys %fields) {
1436 $self->{_permitted}->{$element} = $fields{$element};
1437 }
1438 @{$self}{keys %fields} = values %fields;
1439 return $self;
1440 }
1441 Once we've done this, we don't even need to have an AUTOLOAD function
1443 in the Employee package, because we'll grab Person's version of that
1444 via inheritance, and it will all work out just fine.
1445
1447 Even though proxy methods can provide a more convenient approach to
1448 making more struct-like classes than tediously coding up data methods
1449 as functions, it still leaves a bit to be desired. For one thing, it
1450 means you have to handle bogus calls that you don't mean to trap via
1451 your proxy. It also means you have to be quite careful when dealing
1452 with inheritance, as detailed above.
1453 Perl programmers have responded to this by creating several different
1455 class construction classes. These metaclasses are classes that create
1456 other classes. A couple worth looking at are Class::Struct and Alias.
1457 These and other related metaclasses can be found in the modules direc‐
1458 tory on CPAN.
1459 Class::Struct
1461 One of the older ones is Class::Struct. In fact, its syntax and inter‐
1463 face were sketched out long before perl5 even solidified into a real
1464 thing. What it does is provide you a way to "declare" a class as hav‐
1465 ing objects whose fields are of a specific type. The function that
1466 does this is called, not surprisingly enough, struct(). Because struc‐
1467 tures or records are not base types in Perl, each time you want to cre‐
1468 ate a class to provide a record-like data object, you yourself have to
1469 define a new() method, plus separate data-access methods for each of
1470 that record's fields. You'll quickly become bored with this process.
1471 The Class::Struct::struct() function alleviates this tedium.
1472 Here's a simple example of using it:
1474 use Class::Struct qw(struct);
1476 use Jobbie; # user-defined; see below
1477 struct 'Fred' => {
1479 one => '$',
1480 many => '@',
1481 profession => 'Jobbie', # does not call Jobbie->new()
1482 };
1483 $ob = Fred->new(profession => Jobbie->new());
1485 $ob->one("hmmmm");
1486 $ob->many(0, "here");
1488 $ob->many(1, "you");
1489 $ob->many(2, "go");
1490 print "Just set: ", $ob->many(2), "\n";
1491 $ob->profession->salary(10_000);
1493 You can declare types in the struct to be basic Perl types, or user-
1495 defined types (classes). User types will be initialized by calling
1496 that class's new() method.
1497 Take care that the "Jobbie" object is not created automatically by the
1499 "Fred" class's new() method, so you should specify a "Jobbie" object
1500 when you create an instance of "Fred".
1501 Here's a real-world example of using struct generation. Let's say you
1503 wanted to override Perl's idea of gethostbyname() and gethostbyaddr()
1504 so that they would return objects that acted like C structures. We
1505 don't care about high-falutin' OO gunk. All we want is for these
1506 objects to act like structs in the C sense.
1507 use Socket;
1509 use Net::hostent;
1510 $h = gethostbyname("perl.com"); # object return
1511 printf "perl.com's real name is %s, address %s\n",
1512 $h->name, inet_ntoa($h->addr);
1513 Here's how to do this using the Class::Struct module. The crux is
1515 going to be this call:
1516 struct 'Net::hostent' => [ # note bracket
1518 name => '$',
1519 aliases => '@',
1520 addrtype => '$',
1521 'length' => '$',
1522 addr_list => '@',
1523 ];
1524 Which creates object methods of those names and types. It even creates
1526 a new() method for us.
1527 We could also have implemented our object this way:
1529 struct 'Net::hostent' => { # note brace
1531 name => '$',
1532 aliases => '@',
1533 addrtype => '$',
1534 'length' => '$',
1535 addr_list => '@',
1536 };
1537 and then Class::Struct would have used an anonymous hash as the object
1539 type, instead of an anonymous array. The array is faster and smaller,
1540 but the hash works out better if you eventually want to do inheritance.
1541 Since for this struct-like object we aren't planning on inheritance,
1542 this time we'll opt for better speed and size over better flexibility.
1543 Here's the whole implementation:
1545 package Net::hostent;
1547 use strict;
1548 BEGIN {
1550 use Exporter ();
1551 our @EXPORT = qw(gethostbyname gethostbyaddr gethost);
1552 our @EXPORT_OK = qw(
1553 $h_name @h_aliases
1554 $h_addrtype $h_length
1555 @h_addr_list $h_addr
1556 );
1557 our %EXPORT_TAGS = ( FIELDS => [ @EXPORT_OK, @EXPORT ] );
1558 }
1559 our @EXPORT_OK;
1560 # Class::Struct forbids use of @ISA
1562 sub import { goto &Exporter::import }
1563 use Class::Struct qw(struct);
1565 struct 'Net::hostent' => [
1566 name => '$',
1567 aliases => '@',
1568 addrtype => '$',
1569 'length' => '$',
1570 addr_list => '@',
1571 ];
1572 sub addr { shift->addr_list->[0] }
1574 sub populate (@) {
1576 return unless @_;
1577 my $hob = new(); # Class::Struct made this!
1578 $h_name = $hob->[0] = $_[0];
1579 @h_aliases = @{ $hob->[1] } = split ' ', $_[1];
1580 $h_addrtype = $hob->[2] = $_[2];
1581 $h_length = $hob->[3] = $_[3];
1582 $h_addr = $_[4];
1583 @h_addr_list = @{ $hob->[4] } = @_[ (4 .. $#_) ];
1584 return $hob;
1585 }
1586 sub gethostbyname ($) { populate(CORE::gethostbyname(shift)) }
1588 sub gethostbyaddr ($;$) {
1590 my ($addr, $addrtype);
1591 $addr = shift;
1592 require Socket unless @_;
1593 $addrtype = @_ ? shift : Socket::AF_INET();
1594 populate(CORE::gethostbyaddr($addr, $addrtype))
1595 }
1596 sub gethost($) {
1598 if ($_[0] =~ /^\d+(?:\.\d+(?:\.\d+(?:\.\d+)?)?)?$/) {
1599 require Socket;
1600 &gethostbyaddr(Socket::inet_aton(shift));
1601 } else {
1602 &gethostbyname;
1603 }
1604 }
1605 1;
1607 We've snuck in quite a fair bit of other concepts besides just dynamic
1609 class creation, like overriding core functions, import/export bits,
1610 function prototyping, short-cut function call via &whatever, and func‐
1611 tion replacement with "goto &whatever". These all mostly make sense
1612 from the perspective of a traditional module, but as you can see, we
1613 can also use them in an object module.
1614 You can look at other object-based, struct-like overrides of core func‐
1616 tions in the 5.004 release of Perl in File::stat, Net::hostent,
1617 Net::netent, Net::protoent, Net::servent, Time::gmtime, Time::local‐
1618 time, User::grent, and User::pwent. These modules have a final compo‐
1619 nent that's all lowercase, by convention reserved for compiler pragmas,
1620 because they affect the compilation and change a builtin function.
1621 They also have the type names that a C programmer would most expect.
1622 Data Members as Variables
1624 If you're used to C++ objects, then you're accustomed to being able to
1626 get at an object's data members as simple variables from within a
1627 method. The Alias module provides for this, as well as a good bit
1628 more, such as the possibility of private methods that the object can
1629 call but folks outside the class cannot.
1630 Here's an example of creating a Person using the Alias module. When
1632 you update these magical instance variables, you automatically update
1633 value fields in the hash. Convenient, eh?
1634 package Person;
1636 # this is the same as before...
1638 sub new {
1639 my $class = shift;
1640 my $self = {
1641 NAME => undef,
1642 AGE => undef,
1643 PEERS => [],
1644 };
1645 bless($self, $class);
1646 return $self;
1647 }
1648 use Alias qw(attr);
1650 our ($NAME, $AGE, $PEERS);
1651 sub name {
1653 my $self = attr shift;
1654 if (@_) { $NAME = shift; }
1655 return $NAME;
1656 }
1657 sub age {
1659 my $self = attr shift;
1660 if (@_) { $AGE = shift; }
1661 return $AGE;
1662 }
1663 sub peers {
1665 my $self = attr shift;
1666 if (@_) { @PEERS = @_; }
1667 return @PEERS;
1668 }
1669 sub exclaim {
1671 my $self = attr shift;
1672 return sprintf "Hi, I'm %s, age %d, working with %s",
1673 $NAME, $AGE, join(", ", @PEERS);
1674 }
1675 sub happy_birthday {
1677 my $self = attr shift;
1678 return ++$AGE;
1679 }
1680 The need for the "our" declaration is because what Alias does is play
1682 with package globals with the same name as the fields. To use globals
1683 while "use strict" is in effect, you have to predeclare them. These
1684 package variables are localized to the block enclosing the attr() call
1685 just as if you'd used a local() on them. However, that means that
1686 they're still considered global variables with temporary values, just
1687 as with any other local().
1688 It would be nice to combine Alias with something like Class::Struct or
1690 Class::MethodMaker.
1691
1693 Object Terminology
1694 In the various OO literature, it seems that a lot of different words
1696 are used to describe only a few different concepts. If you're not
1697 already an object programmer, then you don't need to worry about all
1698 these fancy words. But if you are, then you might like to know how to
1699 get at the same concepts in Perl.
1700 For example, it's common to call an object an instance of a class and
1702 to call those objects' methods instance methods. Data fields peculiar
1703 to each object are often called instance data or object attributes, and
1704 data fields common to all members of that class are class data, class
1705 attributes, or static data members.
1706 Also, base class, generic class, and superclass all describe the same
1708 notion, whereas derived class, specific class, and subclass describe
1709 the other related one.
1710 C++ programmers have static methods and virtual methods, but Perl only
1712 has class methods and object methods. Actually, Perl only has methods.
1713 Whether a method gets used as a class or object method is by usage
1714 only. You could accidentally call a class method (one expecting a
1715 string argument) on an object (one expecting a reference), or vice
1716 versa.
1717 From the C++ perspective, all methods in Perl are virtual. This, by
1719 the way, is why they are never checked for function prototypes in the
1720 argument list as regular builtin and user-defined functions can be.
1721 Because a class is itself something of an object, Perl's classes can be
1723 taken as describing both a "class as meta-object" (also called object
1724 factory) philosophy and the "class as type definition" (declaring be‐
1725 haviour, not defining mechanism) idea. C++ supports the latter notion,
1726 but not the former.
1727
1729 The following manpages will doubtless provide more background for this
1730 one: perlmod, perlref, perlobj, perlbot, perltie, and overload.
1731 perlboot is a kinder, gentler introduction to object-oriented program‐
1733 ming.
1734 perltooc provides more detail on class data.
1736 Some modules which might prove interesting are Class::Accessor,
1738 Class::Class, Class::Contract, Class::Data::Inheritable, Class::Method‐
1739 Maker and Tie::SecureHash
1740
1742 Copyright (c) 1997, 1998 Tom Christiansen All rights reserved.
1743 This documentation is free; you can redistribute it and/or modify it
1745 under the same terms as Perl itself.
1746 Irrespective of its distribution, all code examples in this file are
1748 hereby placed into the public domain. You are permitted and encouraged
1749 to use this code in your own programs for fun or for profit as you see
1750 fit. A simple comment in the code giving credit would be courteous but
1751 is not required.
1752
1754 Acknowledgments
1755 Thanks to Larry Wall, Roderick Schertler, Gurusamy Sarathy, Dean
1757 Roehrich, Raphael Manfredi, Brent Halsey, Greg Bacon, Brad Appleton,
1758 and many others for their helpful comments.
1759perl v5.8.8 2006-01-07 PERLTOOT(1)