Integrate perlio:
[p5sagit/p5-mst-13.2.git] / pod / perlboot.pod
1 =head1 NAME
2
3 perlboot - Beginner's Object-Oriented Tutorial
4
5 =head1 DESCRIPTION
6
7 If you're not familiar with objects from other languages, some of the
8 other Perl object documentation may be a little daunting, such as
9 L<perlobj>, a basic reference in using objects, and L<perltoot>, which
10 introduces readers to the peculiarities of Perl's object system in a
11 tutorial way.
12
13 So, let's take a different approach, presuming no prior object
14 experience. It helps if you know about subroutines (L<perlsub>),
15 references (L<perlref> et. seq.), and packages (L<perlmod>), so become
16 familiar with those first if you haven't already.
17
18 =head2 If we could talk to the animals...
19
20 Let's let the animals talk for a moment:
21
22     sub Cow::speak {
23       print "a Cow goes moooo!\n";
24     }
25     sub Horse::speak {
26       print "a Horse goes neigh!\n";
27     }
28     sub Sheep::speak {
29       print "a Sheep goes baaaah!\n"
30     }
31
32     Cow::speak;
33     Horse::speak;
34     Sheep::speak;
35
36 This results in:
37
38     a Cow goes moooo!
39     a Horse goes neigh!
40     a Sheep goes baaaah!
41
42 Nothing spectacular here.  Simple subroutines, albeit from separate
43 packages, and called using the full package name.  So let's create
44 an entire pasture:
45
46     # Cow::speak, Horse::speak, Sheep::speak as before
47     @pasture = qw(Cow Cow Horse Sheep Sheep);
48     foreach $animal (@pasture) {
49       &{$animal."::speak"};
50     }
51
52 This results in:
53
54     a Cow goes moooo!
55     a Cow goes moooo!
56     a Horse goes neigh!
57     a Sheep goes baaaah!
58     a Sheep goes baaaah!
59
60 Wow.  That symbolic coderef de-referencing there is pretty nasty.
61 We're counting on C<no strict subs> mode, certainly not recommended
62 for larger programs.  And why was that necessary?  Because the name of
63 the package seems to be inseparable from the name of the subroutine we
64 want to invoke within that package.
65
66 Or is it?
67
68 =head2 Introducing the method invocation arrow
69
70 For now, let's say that C<< Class->method >> invokes subroutine
71 C<method> in package C<Class>.  (Here, "Class" is used in its
72 "category" meaning, not its "scholastic" meaning.) That's not
73 completely accurate, but we'll do this one step at a time.  Now let's
74 use it like so:
75
76     # Cow::speak, Horse::speak, Sheep::speak as before
77     Cow->speak;
78     Horse->speak;
79     Sheep->speak;
80
81 And once again, this results in:
82
83     a Cow goes moooo!
84     a Horse goes neigh!
85     a Sheep goes baaaah!
86
87 That's not fun yet.  Same number of characters, all constant, no
88 variables.  But yet, the parts are separable now.  Watch:
89
90     $a = "Cow";
91     $a->speak; # invokes Cow->speak
92
93 Ahh!  Now that the package name has been parted from the subroutine
94 name, we can use a variable package name.  And this time, we've got
95 something that works even when C<use strict refs> is enabled.
96
97 =head2 Invoking a barnyard
98
99 Let's take that new arrow invocation and put it back in the barnyard
100 example:
101
102     sub Cow::speak {
103       print "a Cow goes moooo!\n";
104     }
105     sub Horse::speak {
106       print "a Horse goes neigh!\n";
107     }
108     sub Sheep::speak {
109       print "a Sheep goes baaaah!\n"
110     }
111
112     @pasture = qw(Cow Cow Horse Sheep Sheep);
113     foreach $animal (@pasture) {
114       $animal->speak;
115     }
116
117 There!  Now we have the animals all talking, and safely at that,
118 without the use of symbolic coderefs.
119
120 But look at all that common code.  Each of the C<speak> routines has a
121 similar structure: a C<print> operator and a string that contains
122 common text, except for two of the words.  It'd be nice if we could
123 factor out the commonality, in case we decide later to change it all
124 to C<says> instead of C<goes>.
125
126 And we actually have a way of doing that without much fuss, but we
127 have to hear a bit more about what the method invocation arrow is
128 actually doing for us.
129
130 =head2 The extra parameter of method invocation
131
132 The invocation of:
133
134     Class->method(@args)
135
136 attempts to invoke subroutine C<Class::method> as:
137
138     Class::method("Class", @args);
139
140 (If the subroutine can't be found, "inheritance" kicks in, but we'll
141 get to that later.)  This means that we get the class name as the
142 first parameter (the only parameter, if no arguments are given).  So
143 we can rewrite the C<Sheep> speaking subroutine as:
144
145     sub Sheep::speak {
146       my $class = shift;
147       print "a $class goes baaaah!\n";
148     }
149
150 And the other two animals come out similarly:
151
152     sub Cow::speak {
153       my $class = shift;
154       print "a $class goes moooo!\n";
155     }
156     sub Horse::speak {
157       my $class = shift;
158       print "a $class goes neigh!\n";
159     }
160
161 In each case, C<$class> will get the value appropriate for that
162 subroutine.  But once again, we have a lot of similar structure.  Can
163 we factor that out even further?  Yes, by calling another method in
164 the same class.
165
166 =head2 Calling a second method to simplify things
167
168 Let's call out from C<speak> to a helper method called C<sound>.
169 This method provides the constant text for the sound itself.
170
171     { package Cow;
172       sub sound { "moooo" }
173       sub speak {
174         my $class = shift;
175         print "a $class goes ", $class->sound, "!\n"
176       }
177     }
178
179 Now, when we call C<< Cow->speak >>, we get a C<$class> of C<Cow> in
180 C<speak>.  This in turn selects the C<< Cow->sound >> method, which
181 returns C<moooo>.  But how different would this be for the C<Horse>?
182
183     { package Horse;
184       sub sound { "neigh" }
185       sub speak {
186         my $class = shift;
187         print "a $class goes ", $class->sound, "!\n"
188       }
189     }
190
191 Only the name of the package and the specific sound change.  So can we
192 somehow share the definition for C<speak> between the Cow and the
193 Horse?  Yes, with inheritance!
194
195 =head2 Inheriting the windpipes
196
197 We'll define a common subroutine package called C<Animal>, with the
198 definition for C<speak>:
199
200     { package Animal;
201       sub speak {
202         my $class = shift;
203         print "a $class goes ", $class->sound, "!\n"
204       }
205     }
206
207 Then, for each animal, we say it "inherits" from C<Animal>, along
208 with the animal-specific sound:
209
210     { package Cow;
211       @ISA = qw(Animal);
212       sub sound { "moooo" }
213     }
214
215 Note the added C<@ISA> array.  We'll get to that in a minute.
216
217 But what happens when we invoke C<< Cow->speak >> now?
218
219 First, Perl constructs the argument list.  In this case, it's just
220 C<Cow>.  Then Perl looks for C<Cow::speak>.  But that's not there, so
221 Perl checks for the inheritance array C<@Cow::ISA>.  It's there,
222 and contains the single name C<Animal>.
223
224 Perl next checks for C<speak> inside C<Animal> instead, as in
225 C<Animal::speak>.  And that's found, so Perl invokes that subroutine
226 with the already frozen argument list.
227
228 Inside the C<Animal::speak> subroutine, C<$class> becomes C<Cow> (the
229 first argument).  So when we get to the step of invoking
230 C<< $class->sound >>, it'll be looking for C<< Cow->sound >>, which
231 gets it on the first try without looking at C<@ISA>.  Success!
232
233 =head2 A few notes about @ISA
234
235 This magical C<@ISA> variable (pronounced "is a" not "ice-uh"), has
236 declared that C<Cow> "is a" C<Animal>.  Note that it's an array,
237 not a simple single value, because on rare occasions, it makes sense
238 to have more than one parent class searched for the missing methods.
239
240 If C<Animal> also had an C<@ISA>, then we'd check there too.  The
241 search is recursive, depth-first, left-to-right in each C<@ISA>.
242 Typically, each C<@ISA> has only one element (multiple elements means
243 multiple inheritance and multiple headaches), so we get a nice tree of
244 inheritance.
245
246 When we turn on C<use strict>, we'll get complaints on C<@ISA>, since
247 it's not a variable containing an explicit package name, nor is it a
248 lexical ("my") variable.  We can't make it a lexical variable though
249 (it has to belong to the package to be found by the inheritance mechanism),
250 so there's a couple of straightforward ways to handle that.
251
252 The easiest is to just spell the package name out:
253
254     @Cow::ISA = qw(Animal);
255
256 Or allow it as an implicitly named package variable:
257
258     package Cow;
259     use vars qw(@ISA);
260     @ISA = qw(Animal);
261
262 If you're bringing in the class from outside, via an object-oriented
263 module, you change:
264
265     package Cow;
266     use Animal;
267     use vars qw(@ISA);
268     @ISA = qw(Animal);
269
270 into just:
271
272     package Cow;
273     use base qw(Animal);
274
275 And that's pretty darn compact.
276
277 =head2 Overriding the methods
278
279 Let's add a mouse, which can barely be heard:
280
281     # Animal package from before
282     { package Mouse;
283       @ISA = qw(Animal);
284       sub sound { "squeak" }
285       sub speak {
286         my $class = shift;
287         print "a $class goes ", $class->sound, "!\n";
288         print "[but you can barely hear it!]\n";
289       }
290     }
291
292     Mouse->speak;
293
294 which results in:
295
296     a Mouse goes squeak!
297     [but you can barely hear it!]
298
299 Here, C<Mouse> has its own speaking routine, so C<< Mouse->speak >>
300 doesn't immediately invoke C<< Animal->speak >>.  This is known as
301 "overriding".  In fact, we didn't even need to say that a C<Mouse> was
302 an C<Animal> at all, since all of the methods needed for C<speak> are
303 completely defined with C<Mouse>.
304
305 But we've now duplicated some of the code from C<< Animal->speak >>,
306 and this can once again be a maintenance headache.  So, can we avoid
307 that?  Can we say somehow that a C<Mouse> does everything any other
308 C<Animal> does, but add in the extra comment?  Sure!
309
310 First, we can invoke the C<Animal::speak> method directly:
311
312     # Animal package from before
313     { package Mouse;
314       @ISA = qw(Animal);
315       sub sound { "squeak" }
316       sub speak {
317         my $class = shift;
318         Animal::speak($class);
319         print "[but you can barely hear it!]\n";
320       }
321     }
322
323 Note that we have to include the C<$class> parameter (almost surely
324 the value of C<"Mouse">) as the first parameter to C<Animal::speak>,
325 since we've stopped using the method arrow.  Why did we stop?  Well,
326 if we invoke C<< Animal->speak >> there, the first parameter to the
327 method will be C<"Animal"> not C<"Mouse">, and when time comes for it
328 to call for the C<sound>, it won't have the right class to come back
329 to this package.
330
331 Invoking C<Animal::speak> directly is a mess, however.  What if
332 C<Animal::speak> didn't exist before, and was being inherited from a
333 class mentioned in C<@Animal::ISA>?  Because we are no longer using
334 the method arrow, we get one and only one chance to hit the right
335 subroutine.
336
337 Also note that the C<Animal> classname is now hardwired into the
338 subroutine selection.  This is a mess if someone maintains the code,
339 changing C<@ISA> for <Mouse> and didn't notice C<Animal> there in
340 C<speak>.  So, this is probably not the right way to go.
341
342 =head2 Starting the search from a different place
343
344 A better solution is to tell Perl to search from a higher place
345 in the inheritance chain:
346
347     # same Animal as before
348     { package Mouse;
349       # same @ISA, &sound as before
350       sub speak {
351         my $class = shift;
352         $class->Animal::speak;
353         print "[but you can barely hear it!]\n";
354       }
355     }
356
357 Ahh.  This works.  Using this syntax, we start with C<Animal> to find
358 C<speak>, and use all of C<Animal>'s inheritance chain if not found
359 immediately.  And yet the first parameter will be C<$class>, so the
360 found C<speak> method will get C<Mouse> as its first entry, and
361 eventually work its way back to C<Mouse::sound> for the details.
362
363 But this isn't the best solution.  We still have to keep the C<@ISA>
364 and the initial search package coordinated.  Worse, if C<Mouse> had
365 multiple entries in C<@ISA>, we wouldn't necessarily know which one
366 had actually defined C<speak>.  So, is there an even better way?
367
368 =head2 The SUPER way of doing things
369
370 By changing the C<Animal> class to the C<SUPER> class in that
371 invocation, we get a search of all of our super classes (classes
372 listed in C<@ISA>) automatically:
373
374     # same Animal as before
375     { package Mouse;
376       # same @ISA, &sound as before
377       sub speak {
378         my $class = shift;
379         $class->SUPER::speak;
380         print "[but you can barely hear it!]\n";
381       }
382     }
383
384 So, C<SUPER::speak> means look in the current package's C<@ISA> for
385 C<speak>, invoking the first one found.
386
387 =head2 Where we're at so far...
388
389 So far, we've seen the method arrow syntax:
390
391   Class->method(@args);
392
393 or the equivalent:
394
395   $a = "Class";
396   $a->method(@args);
397
398 which constructs an argument list of:
399
400   ("Class", @args)
401
402 and attempts to invoke
403
404   Class::method("Class", @Args);
405
406 However, if C<Class::method> is not found, then C<@Class::ISA> is examined
407 (recursively) to locate a package that does indeed contain C<method>,
408 and that subroutine is invoked instead.
409
410 Using this simple syntax, we have class methods, (multiple)
411 inheritance, overriding, and extending.  Using just what we've seen so
412 far, we've been able to factor out common code, and provide a nice way
413 to reuse implementations with variations.  This is at the core of what
414 objects provide, but objects also provide instance data, which we
415 haven't even begun to cover.
416
417 =head2 A horse is a horse, of course of course -- or is it?
418
419 Let's start with the code for the C<Animal> class
420 and the C<Horse> class:
421
422   { package Animal;
423     sub speak {
424       my $class = shift;
425       print "a $class goes ", $class->sound, "!\n"
426     }
427   }
428   { package Horse;
429     @ISA = qw(Animal);
430     sub sound { "neigh" }
431   }
432
433 This lets us invoke C<< Horse->speak >> to ripple upward to
434 C<Animal::speak>, calling back to C<Horse::sound> to get the specific
435 sound, and the output of:
436
437   a Horse goes neigh!
438
439 But all of our Horse objects would have to be absolutely identical.
440 If I add a subroutine, all horses automatically share it.  That's
441 great for making horses the same, but how do we capture the
442 distinctions about an individual horse?  For example, suppose I want
443 to give my first horse a name.  There's got to be a way to keep its
444 name separate from the other horses.
445
446 We can do that by drawing a new distinction, called an "instance".
447 An "instance" is generally created by a class.  In Perl, any reference
448 can be an instance, so let's start with the simplest reference
449 that can hold a horse's name: a scalar reference.
450
451   my $name = "Mr. Ed";
452   my $talking = \$name;
453
454 So now C<$talking> is a reference to what will be the instance-specific
455 data (the name).  The final step in turning this into a real instance
456 is with a special operator called C<bless>:
457
458   bless $talking, Horse;
459
460 This operator stores information about the package named C<Horse> into
461 the thing pointed at by the reference.  At this point, we say
462 C<$talking> is an instance of C<Horse>.  That is, it's a specific
463 horse.  The reference is otherwise unchanged, and can still be used
464 with traditional dereferencing operators.
465
466 =head2 Invoking an instance method
467
468 The method arrow can be used on instances, as well as names of
469 packages (classes).  So, let's get the sound that C<$talking> makes:
470
471   my $noise = $talking->sound;
472
473 To invoke C<sound>, Perl first notes that C<$talking> is a blessed
474 reference (and thus an instance).  It then constructs an argument
475 list, in this case from just C<($talking)>.  (Later we'll see that
476 arguments will take their place following the instance variable,
477 just like with classes.)
478
479 Now for the fun part: Perl takes the class in which the instance was
480 blessed, in this case C<Horse>, and uses that to locate the subroutine
481 to invoke the method.  In this case, C<Horse::sound> is found directly
482 (without using inheritance), yielding the final subroutine invocation:
483
484   Horse::sound($talking)
485
486 Note that the first parameter here is still the instance, not the name
487 of the class as before.  We'll get C<neigh> as the return value, and
488 that'll end up as the C<$noise> variable above.
489
490 If Horse::sound had not been found, we'd be wandering up the
491 C<@Horse::ISA> list to try to find the method in one of the
492 superclasses, just as for a class method.  The only difference between
493 a class method and an instance method is whether the first parameter
494 is an instance (a blessed reference) or a class name (a string).
495
496 =head2 Accessing the instance data
497
498 Because we get the instance as the first parameter, we can now access
499 the instance-specific data.  In this case, let's add a way to get at
500 the name:
501
502   { package Horse;
503     @ISA = qw(Animal);
504     sub sound { "neigh" }
505     sub name {
506       my $self = shift;
507       $$self;
508     }
509   }
510
511 Now we call for the name:
512
513   print $talking->name, " says ", $talking->sound, "\n";
514
515 Inside C<Horse::name>, the C<@_> array contains just C<$talking>,
516 which the C<shift> stores into C<$self>.  (It's traditional to shift
517 the first parameter off into a variable named C<$self> for instance
518 methods, so stay with that unless you have strong reasons otherwise.)
519 Then, C<$self> gets de-referenced as a scalar ref, yielding C<Mr. Ed>,
520 and we're done with that.  The result is:
521
522   Mr. Ed says neigh.
523
524 =head2 How to build a horse
525
526 Of course, if we constructed all of our horses by hand, we'd most
527 likely make mistakes from time to time.  We're also violating one of
528 the properties of object-oriented programming, in that the "inside
529 guts" of a Horse are visible.  That's good if you're a veterinarian,
530 but not if you just like to own horses.  So, let's let the Horse class
531 build a new horse:
532
533   { package Horse;
534     @ISA = qw(Animal);
535     sub sound { "neigh" }
536     sub name {
537       my $self = shift;
538       $$self;
539     }
540     sub named {
541       my $class = shift;
542       my $name = shift;
543       bless \$name, $class;
544     }
545   }
546
547 Now with the new C<named> method, we can build a horse:
548
549   my $talking = Horse->named("Mr. Ed");
550
551 Notice we're back to a class method, so the two arguments to
552 C<Horse::named> are C<Horse> and C<Mr. Ed>.  The C<bless> operator
553 not only blesses C<$name>, it also returns the reference to C<$name>,
554 so that's fine as a return value.  And that's how to build a horse.
555
556 We've called the constructor C<named> here, so that it quickly denotes
557 the constructor's argument as the name for this particular C<Horse>.
558 You can use different constructors with different names for different
559 ways of "giving birth" to the object (like maybe recording its
560 pedigree or date of birth).  However, you'll find that most people
561 coming to Perl from more limited languages use a single constructor
562 named C<new>, with various ways of interpreting the arguments to
563 C<new>.  Either style is fine, as long as you document your particular
564 way of giving birth to an object.  (And you I<were> going to do that,
565 right?)
566
567 =head2 Inheriting the constructor
568
569 But was there anything specific to C<Horse> in that method?  No.  Therefore,
570 it's also the same recipe for building anything else that inherited from
571 C<Animal>, so let's put it there:
572
573   { package Animal;
574     sub speak {
575       my $class = shift;
576       print "a $class goes ", $class->sound, "!\n"
577     }
578     sub name {
579       my $self = shift;
580       $$self;
581     }
582     sub named {
583       my $class = shift;
584       my $name = shift;
585       bless \$name, $class;
586     }
587   }
588   { package Horse;
589     @ISA = qw(Animal);
590     sub sound { "neigh" }
591   }
592
593 Ahh, but what happens if we invoke C<speak> on an instance?
594
595   my $talking = Horse->named("Mr. Ed");
596   $talking->speak;
597
598 We get a debugging value:
599
600   a Horse=SCALAR(0xaca42ac) goes neigh!
601
602 Why?  Because the C<Animal::speak> routine is expecting a classname as
603 its first parameter, not an instance.  When the instance is passed in,
604 we'll end up using a blessed scalar reference as a string, and that
605 shows up as we saw it just now.
606
607 =head2 Making a method work with either classes or instances
608
609 All we need is for a method to detect if it is being called on a class
610 or called on an instance.  The most straightforward way is with the
611 C<ref> operator.  This returns a string (the classname) when used on a
612 blessed reference, and C<undef> when used on a string (like a
613 classname).  Let's modify the C<name> method first to notice the change:
614
615   sub name {
616     my $either = shift;
617     ref $either
618       ? $$either # it's an instance, return name
619       : "an unnamed $either"; # it's a class, return generic
620   }
621
622 Here, the C<?:> operator comes in handy to select either the
623 dereference or a derived string.  Now we can use this with either an
624 instance or a class.  Note that I've changed the first parameter
625 holder to C<$either> to show that this is intended:
626
627   my $talking = Horse->named("Mr. Ed");
628   print Horse->name, "\n"; # prints "an unnamed Horse\n"
629   print $talking->name, "\n"; # prints "Mr Ed.\n"
630
631 and now we'll fix C<speak> to use this:
632
633   sub speak {
634     my $either = shift;
635     print $either->name, " goes ", $either->sound, "\n";
636   }
637
638 And since C<sound> already worked with either a class or an instance,
639 we're done!
640
641 =head2 Adding parameters to a method
642
643 Let's train our animals to eat:
644
645   { package Animal;
646     sub named {
647       my $class = shift;
648       my $name = shift;
649       bless \$name, $class;
650     }
651     sub name {
652       my $either = shift;
653       ref $either
654         ? $$either # it's an instance, return name
655         : "an unnamed $either"; # it's a class, return generic
656     }
657     sub speak {
658       my $either = shift;
659       print $either->name, " goes ", $either->sound, "\n";
660     }
661     sub eat {
662       my $either = shift;
663       my $food = shift;
664       print $either->name, " eats $food.\n";
665     }
666   }
667   { package Horse;
668     @ISA = qw(Animal);
669     sub sound { "neigh" }
670   }
671   { package Sheep;
672     @ISA = qw(Animal);
673     sub sound { "baaaah" }
674   }
675
676 And now try it out:
677
678   my $talking = Horse->named("Mr. Ed");
679   $talking->eat("hay");
680   Sheep->eat("grass");
681
682 which prints:
683
684   Mr. Ed eats hay.
685   an unnamed Sheep eats grass.
686
687 An instance method with parameters gets invoked with the instance,
688 and then the list of parameters.  So that first invocation is like:
689
690   Animal::eat($talking, "hay");
691
692 =head2 More interesting instances
693
694 What if an instance needs more data?  Most interesting instances are
695 made of many items, each of which can in turn be a reference or even
696 another object.  The easiest way to store these is often in a hash.
697 The keys of the hash serve as the names of parts of the object (often
698 called "instance variables" or "member variables"), and the
699 corresponding values are, well, the values.
700
701 But how do we turn the horse into a hash?  Recall that an object was
702 any blessed reference.  We can just as easily make it a blessed hash
703 reference as a blessed scalar reference, as long as everything that
704 looks at the reference is changed accordingly.
705
706 Let's make a sheep that has a name and a color:
707
708   my $bad = bless { Name => "Evil", Color => "black" }, Sheep;
709
710 so C<< $bad->{Name} >> has C<Evil>, and C<< $bad->{Color} >> has
711 C<black>.  But we want to make C<< $bad->name >> access the name, and
712 that's now messed up because it's expecting a scalar reference.  Not
713 to worry, because that's pretty easy to fix up:
714
715   ## in Animal
716   sub name {
717     my $either = shift;
718     ref $either ?
719       $either->{Name} :
720       "an unnamed $either";
721   }
722
723 And of course C<named> still builds a scalar sheep, so let's fix that
724 as well:
725
726   ## in Animal
727   sub named {
728     my $class = shift;
729     my $name = shift;
730     my $self = { Name => $name, Color => $class->default_color };
731     bless $self, $class;
732   }
733
734 What's this C<default_color>?  Well, if C<named> has only the name,
735 we still need to set a color, so we'll have a class-specific initial color.
736 For a sheep, we might define it as white:
737
738   ## in Sheep
739   sub default_color { "white" }
740
741 And then to keep from having to define one for each additional class,
742 we'll define a "backstop" method that serves as the "default default",
743 directly in C<Animal>:
744
745   ## in Animal
746   sub default_color { "brown" }
747
748 Now, because C<name> and C<named> were the only methods that
749 referenced the "structure" of the object, the rest of the methods can
750 remain the same, so C<speak> still works as before.
751
752 =head2 A horse of a different color
753
754 But having all our horses be brown would be boring.  So let's add a
755 method or two to get and set the color.
756
757   ## in Animal
758   sub color {
759     $_[0]->{Color}
760   }
761   sub set_color {
762     $_[0]->{Color} = $_[1];
763   }
764
765 Note the alternate way of accessing the arguments: C<$_[0]> is used
766 in-place, rather than with a C<shift>.  (This saves us a bit of time
767 for something that may be invoked frequently.)  And now we can fix
768 that color for Mr. Ed:
769
770   my $talking = Horse->named("Mr. Ed");
771   $talking->set_color("black-and-white");
772   print $talking->name, " is colored ", $talking->color, "\n";
773
774 which results in:
775
776   Mr. Ed is colored black-and-white
777
778 =head2 Summary
779
780 So, now we have class methods, constructors, instance methods,
781 instance data, and even accessors.  But that's still just the
782 beginning of what Perl has to offer.  We haven't even begun to talk
783 about accessors that double as getters and setters, destructors,
784 indirect object notation, subclasses that add instance data, per-class
785 data, overloading, "isa" and "can" tests, C<UNIVERSAL> class, and so
786 on.  That's for the rest of the Perl documentation to cover.
787 Hopefully, this gets you started, though.
788
789 =head1 SEE ALSO
790
791 For more information, see L<perlobj> (for all the gritty details about
792 Perl objects, now that you've seen the basics), L<perltoot> (the
793 tutorial for those who already know objects), L<perltooc> (dealing
794 with class data), L<perlbot> (for some more tricks), and books such as
795 Damian Conway's excellent I<Object Oriented Perl>.
796
797 Some modules which might prove interesting are Class::Accessor,
798 Class::Class, Class::Contract, Class::Data::Inheritable,
799 Class::MethodMaker and Tie::SecureHash
800
801 =head1 COPYRIGHT
802
803 Copyright (c) 1999, 2000 by Randal L. Schwartz and Stonehenge
804 Consulting Services, Inc.  Permission is hereby granted to distribute
805 this document intact with the Perl distribution, and in accordance
806 with the licenses of the Perl distribution; derived documents must
807 include this copyright notice intact.
808
809 Portions of this text have been derived from Perl Training materials
810 originally appearing in the I<Packages, References, Objects, and
811 Modules> course taught by instructors for Stonehenge Consulting
812 Services, Inc. and used with permission.
813
814 Portions of this text have been derived from materials originally
815 appearing in I<Linux Magazine> and used with permission.