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