Remove C variables (and a parameter!) now unused since -P bit the dust.
[perl.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> by
242 default (see L<mro> for alternatives).  Typically, each C<@ISA> has
243 only one element (multiple elements means multiple inheritance and
244 multiple headaches), so we get a nice tree of 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 C<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. Note that it does I<not> look in
386 the C<@ISA> of C<$class>.
387
388 =head2 Where we're at so far...
389
390 So far, we've seen the method arrow syntax:
391
392   Class->method(@args);
393
394 or the equivalent:
395
396   $a = "Class";
397   $a->method(@args);
398
399 which constructs an argument list of:
400
401   ("Class", @args)
402
403 and attempts to invoke
404
405   Class::method("Class", @Args);
406
407 However, if C<Class::method> is not found, then C<@Class::ISA> is examined
408 (recursively) to locate a package that does indeed contain C<method>,
409 and that subroutine is invoked instead.
410
411 Using this simple syntax, we have class methods, (multiple)
412 inheritance, overriding, and extending.  Using just what we've seen so
413 far, we've been able to factor out common code, and provide a nice way
414 to reuse implementations with variations.  This is at the core of what
415 objects provide, but objects also provide instance data, which we
416 haven't even begun to cover.
417
418 =head2 A horse is a horse, of course of course -- or is it?
419
420 Let's start with the code for the C<Animal> class
421 and the C<Horse> class:
422
423   { package Animal;
424     sub speak {
425       my $class = shift;
426       print "a $class goes ", $class->sound, "!\n";
427     }
428   }
429   { package Horse;
430     @ISA = qw(Animal);
431     sub sound { "neigh" }
432   }
433
434 This lets us invoke C<< Horse->speak >> to ripple upward to
435 C<Animal::speak>, calling back to C<Horse::sound> to get the specific
436 sound, and the output of:
437
438   a Horse goes neigh!
439
440 But all of our Horse objects would have to be absolutely identical.
441 If I add a subroutine, all horses automatically share it.  That's
442 great for making horses the same, but how do we capture the
443 distinctions about an individual horse?  For example, suppose I want
444 to give my first horse a name.  There's got to be a way to keep its
445 name separate from the other horses.
446
447 We can do that by drawing a new distinction, called an "instance".
448 An "instance" is generally created by a class.  In Perl, any reference
449 can be an instance, so let's start with the simplest reference
450 that can hold a horse's name: a scalar reference.
451
452   my $name = "Mr. Ed";
453   my $talking = \$name;
454
455 So now C<$talking> is a reference to what will be the instance-specific
456 data (the name).  The final step in turning this into a real instance
457 is with a special operator called C<bless>:
458
459   bless $talking, Horse;
460
461 This operator stores information about the package named C<Horse> into
462 the thing pointed at by the reference.  At this point, we say
463 C<$talking> is an instance of C<Horse>.  That is, it's a specific
464 horse.  The reference is otherwise unchanged, and can still be used
465 with traditional dereferencing operators.
466
467 =head2 Invoking an instance method
468
469 The method arrow can be used on instances, as well as names of
470 packages (classes).  So, let's get the sound that C<$talking> makes:
471
472   my $noise = $talking->sound;
473
474 To invoke C<sound>, Perl first notes that C<$talking> is a blessed
475 reference (and thus an instance).  It then constructs an argument
476 list, in this case from just C<($talking)>.  (Later we'll see that
477 arguments will take their place following the instance variable,
478 just like with classes.)
479
480 Now for the fun part: Perl takes the class in which the instance was
481 blessed, in this case C<Horse>, and uses that to locate the subroutine
482 to invoke the method.  In this case, C<Horse::sound> is found directly
483 (without using inheritance), yielding the final subroutine invocation:
484
485   Horse::sound($talking)
486
487 Note that the first parameter here is still the instance, not the name
488 of the class as before.  We'll get C<neigh> as the return value, and
489 that'll end up as the C<$noise> variable above.
490
491 If Horse::sound had not been found, we'd be wandering up the
492 C<@Horse::ISA> list to try to find the method in one of the
493 superclasses, just as for a class method.  The only difference between
494 a class method and an instance method is whether the first parameter
495 is an instance (a blessed reference) or a class name (a string).
496
497 =head2 Accessing the instance data
498
499 Because we get the instance as the first parameter, we can now access
500 the instance-specific data.  In this case, let's add a way to get at
501 the name:
502
503   { package Horse;
504     @ISA = qw(Animal);
505     sub sound { "neigh" }
506     sub name {
507       my $self = shift;
508       $$self;
509     }
510   }
511
512 Now we call for the name:
513
514   print $talking->name, " says ", $talking->sound, "\n";
515
516 Inside C<Horse::name>, the C<@_> array contains just C<$talking>,
517 which the C<shift> stores into C<$self>.  (It's traditional to shift
518 the first parameter off into a variable named C<$self> for instance
519 methods, so stay with that unless you have strong reasons otherwise.)
520 Then, C<$self> gets de-referenced as a scalar ref, yielding C<Mr. Ed>,
521 and we're done with that.  The result is:
522
523   Mr. Ed says neigh.
524
525 =head2 How to build a horse
526
527 Of course, if we constructed all of our horses by hand, we'd most
528 likely make mistakes from time to time.  We're also violating one of
529 the properties of object-oriented programming, in that the "inside
530 guts" of a Horse are visible.  That's good if you're a veterinarian,
531 but not if you just like to own horses.  So, let's let the Horse class
532 build a new horse:
533
534   { package Horse;
535     @ISA = qw(Animal);
536     sub sound { "neigh" }
537     sub name {
538       my $self = shift;
539       $$self;
540     }
541     sub named {
542       my $class = shift;
543       my $name = shift;
544       bless \$name, $class;
545     }
546   }
547
548 Now with the new C<named> method, we can build a horse:
549
550   my $talking = Horse->named("Mr. Ed");
551
552 Notice we're back to a class method, so the two arguments to
553 C<Horse::named> are C<Horse> and C<Mr. Ed>.  The C<bless> operator
554 not only blesses C<$name>, it also returns the reference to C<$name>,
555 so that's fine as a return value.  And that's how to build a horse.
556
557 We've called the constructor C<named> here, so that it quickly denotes
558 the constructor's argument as the name for this particular C<Horse>.
559 You can use different constructors with different names for different
560 ways of "giving birth" to the object (like maybe recording its
561 pedigree or date of birth).  However, you'll find that most people
562 coming to Perl from more limited languages use a single constructor
563 named C<new>, with various ways of interpreting the arguments to
564 C<new>.  Either style is fine, as long as you document your particular
565 way of giving birth to an object.  (And you I<were> going to do that,
566 right?)
567
568 =head2 Inheriting the constructor
569
570 But was there anything specific to C<Horse> in that method?  No.  Therefore,
571 it's also the same recipe for building anything else that inherited from
572 C<Animal>, so let's put it there:
573
574   { package Animal;
575     sub speak {
576       my $class = shift;
577       print "a $class goes ", $class->sound, "!\n";
578     }
579     sub name {
580       my $self = shift;
581       $$self;
582     }
583     sub named {
584       my $class = shift;
585       my $name = shift;
586       bless \$name, $class;
587     }
588   }
589   { package Horse;
590     @ISA = qw(Animal);
591     sub sound { "neigh" }
592   }
593
594 Ahh, but what happens if we invoke C<speak> on an instance?
595
596   my $talking = Horse->named("Mr. Ed");
597   $talking->speak;
598
599 We get a debugging value:
600
601   a Horse=SCALAR(0xaca42ac) goes neigh!
602
603 Why?  Because the C<Animal::speak> routine is expecting a classname as
604 its first parameter, not an instance.  When the instance is passed in,
605 we'll end up using a blessed scalar reference as a string, and that
606 shows up as we saw it just now.
607
608 =head2 Making a method work with either classes or instances
609
610 All we need is for a method to detect if it is being called on a class
611 or called on an instance.  The most straightforward way is with the
612 C<ref> operator.  This returns a string (the classname) when used on a
613 blessed reference, and an empty string when used on a string (like a
614 classname).  Let's modify the C<name> method first to notice the change:
615
616   sub name {
617     my $either = shift;
618     ref $either
619       ? $$either # it's an instance, return name
620       : "an unnamed $either"; # it's a class, return generic
621   }
622
623 Here, the C<?:> operator comes in handy to select either the
624 dereference or a derived string.  Now we can use this with either an
625 instance or a class.  Note that I've changed the first parameter
626 holder to C<$either> to show that this is intended:
627
628   my $talking = Horse->named("Mr. Ed");
629   print Horse->name, "\n"; # prints "an unnamed Horse\n"
630   print $talking->name, "\n"; # prints "Mr Ed.\n"
631
632 and now we'll fix C<speak> to use this:
633
634   sub speak {
635     my $either = shift;
636     print $either->name, " goes ", $either->sound, "\n";
637   }
638
639 And since C<sound> already worked with either a class or an instance,
640 we're done!
641
642 =head2 Adding parameters to a method
643
644 Let's train our animals to eat:
645
646   { package Animal;
647     sub named {
648       my $class = shift;
649       my $name = shift;
650       bless \$name, $class;
651     }
652     sub name {
653       my $either = shift;
654       ref $either
655         ? $$either # it's an instance, return name
656         : "an unnamed $either"; # it's a class, return generic
657     }
658     sub speak {
659       my $either = shift;
660       print $either->name, " goes ", $either->sound, "\n";
661     }
662     sub eat {
663       my $either = shift;
664       my $food = shift;
665       print $either->name, " eats $food.\n";
666     }
667   }
668   { package Horse;
669     @ISA = qw(Animal);
670     sub sound { "neigh" }
671   }
672   { package Sheep;
673     @ISA = qw(Animal);
674     sub sound { "baaaah" }
675   }
676
677 And now try it out:
678
679   my $talking = Horse->named("Mr. Ed");
680   $talking->eat("hay");
681   Sheep->eat("grass");
682
683 which prints:
684
685   Mr. Ed eats hay.
686   an unnamed Sheep eats grass.
687
688 An instance method with parameters gets invoked with the instance,
689 and then the list of parameters.  So that first invocation is like:
690
691   Animal::eat($talking, "hay");
692
693 =head2 More interesting instances
694
695 What if an instance needs more data?  Most interesting instances are
696 made of many items, each of which can in turn be a reference or even
697 another object.  The easiest way to store these is often in a hash.
698 The keys of the hash serve as the names of parts of the object (often
699 called "instance variables" or "member variables"), and the
700 corresponding values are, well, the values.
701
702 But how do we turn the horse into a hash?  Recall that an object was
703 any blessed reference.  We can just as easily make it a blessed hash
704 reference as a blessed scalar reference, as long as everything that
705 looks at the reference is changed accordingly.
706
707 Let's make a sheep that has a name and a color:
708
709   my $bad = bless { Name => "Evil", Color => "black" }, Sheep;
710
711 so C<< $bad->{Name} >> has C<Evil>, and C<< $bad->{Color} >> has
712 C<black>.  But we want to make C<< $bad->name >> access the name, and
713 that's now messed up because it's expecting a scalar reference.  Not
714 to worry, because that's pretty easy to fix up:
715
716   ## in Animal
717   sub name {
718     my $either = shift;
719     ref $either ?
720       $either->{Name} :
721       "an unnamed $either";
722   }
723
724 And of course C<named> still builds a scalar sheep, so let's fix that
725 as well:
726
727   ## in Animal
728   sub named {
729     my $class = shift;
730     my $name = shift;
731     my $self = { Name => $name, Color => $class->default_color };
732     bless $self, $class;
733   }
734
735 What's this C<default_color>?  Well, if C<named> has only the name,
736 we still need to set a color, so we'll have a class-specific initial color.
737 For a sheep, we might define it as white:
738
739   ## in Sheep
740   sub default_color { "white" }
741
742 And then to keep from having to define one for each additional class,
743 we'll define a "backstop" method that serves as the "default default",
744 directly in C<Animal>:
745
746   ## in Animal
747   sub default_color { "brown" }
748
749 Now, because C<name> and C<named> were the only methods that
750 referenced the "structure" of the object, the rest of the methods can
751 remain the same, so C<speak> still works as before.
752
753 =head2 A horse of a different color
754
755 But having all our horses be brown would be boring.  So let's add a
756 method or two to get and set the color.
757
758   ## in Animal
759   sub color {
760     $_[0]->{Color}
761   }
762   sub set_color {
763     $_[0]->{Color} = $_[1];
764   }
765
766 Note the alternate way of accessing the arguments: C<$_[0]> is used
767 in-place, rather than with a C<shift>.  (This saves us a bit of time
768 for something that may be invoked frequently.)  And now we can fix
769 that color for Mr. Ed:
770
771   my $talking = Horse->named("Mr. Ed");
772   $talking->set_color("black-and-white");
773   print $talking->name, " is colored ", $talking->color, "\n";
774
775 which results in:
776
777   Mr. Ed is colored black-and-white
778
779 =head2 Summary
780
781 So, now we have class methods, constructors, instance methods,
782 instance data, and even accessors.  But that's still just the
783 beginning of what Perl has to offer.  We haven't even begun to talk
784 about accessors that double as getters and setters, destructors,
785 indirect object notation, subclasses that add instance data, per-class
786 data, overloading, "isa" and "can" tests, C<UNIVERSAL> class, and so
787 on.  That's for the rest of the Perl documentation to cover.
788 Hopefully, this gets you started, though.
789
790 =head1 SEE ALSO
791
792 For more information, see L<perlobj> (for all the gritty details about
793 Perl objects, now that you've seen the basics), L<perltoot> (the
794 tutorial for those who already know objects), L<perltooc> (dealing
795 with class data), L<perlbot> (for some more tricks), and books such as
796 Damian Conway's excellent I<Object Oriented Perl>.
797
798 Some modules which might prove interesting are Class::Accessor,
799 Class::Class, Class::Contract, Class::Data::Inheritable,
800 Class::MethodMaker and Tie::SecureHash
801
802 =head1 COPYRIGHT
803
804 Copyright (c) 1999, 2000 by Randal L. Schwartz and Stonehenge
805 Consulting Services, Inc.  Permission is hereby granted to distribute
806 this document intact with the Perl distribution, and in accordance
807 with the licenses of the Perl distribution; derived documents must
808 include this copyright notice intact.
809
810 Portions of this text have been derived from Perl Training materials
811 originally appearing in the I<Packages, References, Objects, and
812 Modules> course taught by instructors for Stonehenge Consulting
813 Services, Inc. and used with permission.
814
815 Portions of this text have been derived from materials originally
816 appearing in I<Linux Magazine> and used with permission.