[Summary view] [Print] [Text view]

   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.