Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

X11R7.4 - man page for perltoot (x11r4 section 1)

PERLTOOT(1)			 Perl Programmers Reference Guide		      PERLTOOT(1)

       perltoot - Tom's object-oriented tutorial for perl

       Object-oriented programming is a big seller these days.	Some managers would rather have
       objects than sliced bread.  Why is that?  What's so special about an object?  Just what is
       an object anyway?

       An object is nothing but a way of tucking away complex behaviours into a neat little easy-
       to-use bundle.  (This is what professors call abstraction.) Smart people who have nothing
       to do but sit around for weeks on end figuring out really hard problems make these nifty
       objects that even regular people can use. (This is what professors call software reuse.)
       Users (well, programmers) can play with this little bundle all they want, but they aren't
       to open it up and mess with the insides.  Just like an expensive piece of hardware, the
       contract says that you void the warranty if you muck with the cover.  So don't do that.

       The heart of objects is the class, a protected little private namespace full of data and
       functions.  A class is a set of related routines that addresses some problem area.  You
       can think of it as a user-defined type.	The Perl package mechanism, also used for more
       traditional modules, is used for class modules as well.	Objects "live" in a class, mean-
       ing that they belong to some package.

       More often than not, the class provides the user with little bundles.  These bundles are
       objects.  They know whose class they belong to, and how to behave.  Users ask the class to
       do something, like "give me an object."	Or they can ask one of these objects to do some-
       thing.  Asking a class to do something for you is calling a class method.  Asking an
       object to do something for you is calling an object method.  Asking either a class (usu-
       ally) or an object (sometimes) to give you back an object is calling a constructor, which
       is just a kind of method.

       That's all well and good, but how is an object different from any other Perl data type?
       Just what is an object really; that is, what's its fundamental type?  The answer to the
       first question is easy.	An object is different from any other data type in Perl in one
       and only one way: you may dereference it using not merely string or numeric subscripts as
       with simple arrays and hashes, but with named subroutine calls.	In a word, with methods.

       The answer to the second question is that it's a reference, and not just any reference,
       mind you, but one whose referent has been bless()ed into a particular class (read: pack-
       age).  What kind of reference?  Well, the answer to that one is a bit less concrete.
       That's because in Perl the designer of the class can employ any sort of reference they'd
       like as the underlying intrinsic data type.  It could be a scalar, an array, or a hash
       reference.  It could even be a code reference.  But because of its inherent flexibility,
       an object is usually a hash reference.

Creating a Class
       Before you create a class, you need to decide what to name it.  That's because the class
       (package) name governs the name of the file used to house it, just as with regular mod-
       ules.  Then, that class (package) should provide one or more ways to generate objects.
       Finally, it should provide mechanisms to allow users of its objects to indirectly manipu-
       late these objects from a distance.

       For example, let's make a simple Person class module.  It gets stored in the file Per-
       son.pm.	If it were called a Happy::Person class, it would be stored in the file
       Happy/Person.pm, and its package would become Happy::Person instead of just Person.  (On a
       personal computer not running Unix or Plan 9, but something like Mac OS or VMS, the direc-
       tory separator may be different, but the principle is the same.)  Do not assume any formal
       relationship between modules based on their directory names.  This is merely a grouping
       convenience, and has no effect on inheritance, variable accessibility, or anything else.

       For this module we aren't going to use Exporter, because we're a well-behaved class module
       that doesn't export anything at all.  In order to manufacture objects, a class needs to
       have a constructor method.  A constructor gives you back not just a regular data type, but
       a brand-new object in that class.  This magic is taken care of by the bless() function,
       whose sole purpose is to enable its referent to be used as an object.  Remember: being an
       object really means nothing more than that methods may now be called against it.

       While a constructor may be named anything you'd like, most Perl programmers seem to like
       to call theirs new().  However, new() is not a reserved word, and a class is under no
       obligation to supply such.  Some programmers have also been known to use a function with
       the same name as the class as the constructor.

       Object Representation

       By far the most common mechanism used in Perl to represent a Pascal record, a C struct, or
       a C++ class is an anonymous hash.  That's because a hash has an arbitrary number of data
       fields, each conveniently accessed by an arbitrary name of your own devising.

       If you were just doing a simple struct-like emulation, you would likely go about it some-
       thing like this:

	   $rec = {
	       name  => "Jason",
	       age   => 23,
	       peers => [ "Norbert", "Rhys", "Phineas"],

       If you felt like it, you could add a bit of visual distinction by up-casing the hash keys:

	   $rec = {
	       NAME  => "Jason",
	       AGE   => 23,
	       PEERS => [ "Norbert", "Rhys", "Phineas"],

       And so you could get at "$rec->{NAME}" to find "Jason", or "@{ $rec->{PEERS} }" to get at
       "Norbert", "Rhys", and "Phineas".  (Have you ever noticed how many 23-year-old programmers
       seem to be named "Jason" these days? :-)

       This same model is often used for classes, although it is not considered the pinnacle of
       programming propriety for folks from outside the class to come waltzing into an object,
       brazenly accessing its data members directly.  Generally speaking, an object should be
       considered an opaque cookie that you use object methods to access.  Visually, methods look
       like you're dereffing a reference using a function name instead of brackets or braces.

       Class Interface

       Some languages provide a formal syntactic interface to a class's methods, but Perl does
       not.  It relies on you to read the documentation of each class.	If you try to call an
       undefined method on an object, Perl won't complain, but the program will trigger an excep-
       tion while it's running.  Likewise, if you call a method expecting a prime number as its
       argument with a non-prime one instead, you can't expect the compiler to catch this.
       (Well, you can expect it all you like, but it's not going to happen.)

       Let's suppose you have a well-educated user of your Person class, someone who has read the
       docs that explain the prescribed interface.  Here's how they might use the Person class:

	   use Person;

	   $him = Person->new();
	   $him->peers( "Norbert", "Rhys", "Phineas" );

	   push @All_Recs, $him;  # save object in array for later

	   printf "%s is %d years old.\n", $him->name, $him->age;
	   print "His peers are: ", join(", ", $him->peers), "\n";

	   printf "Last rec's name is %s\n", $All_Recs[-1]->name;

       As you can see, the user of the class doesn't know (or at least, has no business paying
       attention to the fact) that the object has one particular implementation or another.  The
       interface to the class and its objects is exclusively via methods, and that's all the user
       of the class should ever play with.

       Constructors and Instance Methods

       Still, someone has to know what's in the object.  And that someone is the class.  It
       implements methods that the programmer uses to access the object.  Here's how to implement
       the Person class using the standard hash-ref-as-an-object idiom.  We'll make a class
       method called new() to act as the constructor, and three object methods called name(),
       age(), and peers() to get at per-object data hidden away in our anonymous hash.

	   package Person;
	   use strict;

	   ## the object constructor (simplistic version)  ##
	   sub new {
	       my $self  = {};
	       $self->{NAME}   = undef;
	       $self->{AGE}    = undef;
	       $self->{PEERS}  = [];
	       bless($self);	       # but see below
	       return $self;

	   ## methods to access per-object data        ##
	   ##					       ##
	   ## With args, they set the value.  Without  ##
	   ## any, they only retrieve it/them.	       ##

	   sub name {
	       my $self = shift;
	       if (@_) { $self->{NAME} = shift }
	       return $self->{NAME};

	   sub age {
	       my $self = shift;
	       if (@_) { $self->{AGE} = shift }
	       return $self->{AGE};

	   sub peers {
	       my $self = shift;
	       if (@_) { @{ $self->{PEERS} } = @_ }
	       return @{ $self->{PEERS} };

	   1;  # so the require or use succeeds

       We've created three methods to access an object's data, name(), age(), and peers().  These
       are all substantially similar.  If called with an argument, they set the appropriate
       field; otherwise they return the value held by that field, meaning the value of that hash

       Planning for the Future: Better Constructors

       Even though at this point you may not even know what it means, someday you're going to
       worry about inheritance.  (You can safely ignore this for now and worry about it later if
       you'd like.)  To ensure that this all works out smoothly, you must use the double-argument
       form of bless().  The second argument is the class into which the referent will be
       blessed.  By not assuming our own class as the default second argument and instead using
       the class passed into us, we make our constructor inheritable.

	   sub new {
	       my $class = shift;
	       my $self  = {};
	       $self->{NAME}   = undef;
	       $self->{AGE}    = undef;
	       $self->{PEERS}  = [];
	       bless ($self, $class);
	       return $self;

       That's about all there is for constructors.  These methods bring objects to life, return-
       ing neat little opaque bundles to the user to be used in subsequent method calls.


       Every story has a beginning and an end.	The beginning of the object's story is its con-
       structor, explicitly called when the object comes into existence.  But the ending of its
       story is the destructor, a method implicitly called when an object leaves this life.  Any
       per-object clean-up code is placed in the destructor, which must (in Perl) be called

       If constructors can have arbitrary names, then why not destructors?  Because while a con-
       structor is explicitly called, a destructor is not.  Destruction happens automatically via
       Perl's garbage collection (GC) system, which is a quick but somewhat lazy reference-based
       GC system.  To know what to call, Perl insists that the destructor be named DESTROY.
       Perl's notion of the right time to call a destructor is not well-defined currently, which
       is why your destructors should not rely on when they are called.

       Why is DESTROY in all caps?  Perl on occasion uses purely uppercase function names as a
       convention to indicate that the function will be automatically called by Perl in some way.
       Others that are called implicitly include BEGIN, END, AUTOLOAD, plus all methods used by
       tied objects, described in perltie.

       In really good object-oriented programming languages, the user doesn't care when the
       destructor is called.  It just happens when it's supposed to.  In low-level languages
       without any GC at all, there's no way to depend on this happening at the right time, so
       the programmer must explicitly call the destructor to clean up memory and state, crossing
       their fingers that it's the right time to do so.   Unlike C++, an object destructor is
       nearly never needed in Perl, and even when it is, explicit invocation is uncalled for.  In
       the case of our Person class, we don't need a destructor because Perl takes care of simple
       matters like memory deallocation.

       The only situation where Perl's reference-based GC won't work is when there's a circular-
       ity in the data structure, such as:

	   $this->{WHATEVER} = $this;

       In that case, you must delete the self-reference manually if you expect your program not
       to leak memory.	While admittedly error-prone, this is the best we can do right now.
       Nonetheless, rest assured that when your program is finished, its objects' destructors are
       all duly called.  So you are guaranteed that an object eventually gets properly destroyed,
       except in the unique case of a program that never exits.  (If you're running Perl embedded
       in another application, this full GC pass happens a bit more frequently--whenever a thread
       shuts down.)

       Other Object Methods

       The methods we've talked about so far have either been constructors or else simple "data
       methods", interfaces to data stored in the object.  These are a bit like an object's data
       members in the C++ world, except that strangers don't access them as data.  Instead, they
       should only access the object's data indirectly via its methods.  This is an important
       rule: in Perl, access to an object's data should only be made through methods.

       Perl doesn't impose restrictions on who gets to use which methods.  The public-versus-pri-
       vate distinction is by convention, not syntax.  (Well, unless you use the Alias module
       described below in "Data Members as Variables".)  Occasionally you'll see method names
       beginning or ending with an underscore or two.  This marking is a convention indicating
       that the methods are private to that class alone and sometimes to its closest acquain-
       tances, its immediate subclasses.  But this distinction is not enforced by Perl itself.
       It's up to the programmer to behave.

       There's no reason to limit methods to those that simply access data.  Methods can do any-
       thing at all.  The key point is that they're invoked against an object or a class.  Let's
       say we'd like object methods that do more than fetch or set one particular field.

	   sub exclaim {
	       my $self = shift;
	       return sprintf "Hi, I'm %s, age %d, working with %s",
		   $self->{NAME}, $self->{AGE}, join(", ", @{$self->{PEERS}});

       Or maybe even one like this:

	   sub happy_birthday {
	       my $self = shift;
	       return ++$self->{AGE};

       Some might argue that one should go at these this way:

	   sub exclaim {
	       my $self = shift;
	       return sprintf "Hi, I'm %s, age %d, working with %s",
		   $self->name, $self->age, join(", ", $self->peers);

	   sub happy_birthday {
	       my $self = shift;
	       return $self->age( $self->age() + 1 );

       But since these methods are all executing in the class itself, this may not be critical.
       There are tradeoffs to be made.	Using direct hash access is faster (about an order of
       magnitude faster, in fact), and it's more convenient when you want to interpolate in
       strings.  But using methods (the external interface) internally shields not just the users
       of your class but even you yourself from changes in your data representation.

Class Data
       What about "class data", data items common to each object in a class?  What would you want
       that for?  Well, in your Person class, you might like to keep track of the total people
       alive.  How do you implement that?

       You could make it a global variable called $Person::Census.  But about only reason you'd
       do that would be if you wanted people to be able to get at your class data directly.  They
       could just say $Person::Census and play around with it.	Maybe this is ok in your design
       scheme.	You might even conceivably want to make it an exported variable.  To be
       exportable, a variable must be a (package) global.  If this were a traditional module
       rather than an object-oriented one, you might do that.

       While this approach is expected in most traditional modules, it's generally considered
       rather poor form in most object modules.  In an object module, you should set up a protec-
       tive veil to separate interface from implementation.  So provide a class method to access
       class data just as you provide object methods to access object data.

       So, you could still keep $Census as a package global and rely upon others to honor the
       contract of the module and therefore not play around with its implementation.  You could
       even be supertricky and make $Census a tied object as described in perltie, thereby inter-
       cepting all accesses.

       But more often than not, you just want to make your class data a file-scoped lexical.  To
       do so, simply put this at the top of the file:

	   my $Census = 0;

       Even though the scope of a my() normally expires when the block in which it was declared
       is done (in this case the whole file being required or used), Perl's deep binding of lexi-
       cal variables guarantees that the variable will not be deallocated, remaining accessible
       to functions declared within that scope.  This doesn't work with global variables given
       temporary values via local(), though.

       Irrespective of whether you leave $Census a package global or make it instead a file-
       scoped lexical, you should make these changes to your Person::new() constructor:

	   sub new {
	       my $class = shift;
	       my $self  = {};
	       $self->{NAME}   = undef;
	       $self->{AGE}    = undef;
	       $self->{PEERS}  = [];
	       bless ($self, $class);
	       return $self;

	   sub population {
	       return $Census;

       Now that we've done this, we certainly do need a destructor so that when Person is
       destroyed, the $Census goes down.  Here's how this could be done:

	   sub DESTROY { --$Census }

       Notice how there's no memory to deallocate in the destructor?  That's something that Perl
       takes care of for you all by itself.

       Alternatively, you could use the Class::Data::Inheritable module from CPAN.

       Accessing Class Data

       It turns out that this is not really a good way to go about handling class data.  A good
       scalable rule is that you must never reference class data directly from an object method.
       Otherwise you aren't building a scalable, inheritable class.  The object must be the ren-
       dezvous point for all operations, especially from an object method.  The globals (class
       data) would in some sense be in the "wrong" package in your derived classes.  In Perl,
       methods execute in the context of the class they were defined in, not that of the object
       that triggered them.  Therefore, namespace visibility of package globals in methods is
       unrelated to inheritance.

       Got that?  Maybe not.  Ok, let's say that some other class "borrowed" (well, inherited)
       the DESTROY method as it was defined above.  When those objects are destroyed, the origi-
       nal $Census variable will be altered, not the one in the new class's package namespace.
       Perhaps this is what you want, but probably it isn't.

       Here's how to fix this.	We'll store a reference to the data in the value accessed by the
       hash key "_CENSUS".  Why the underscore?  Well, mostly because an initial underscore
       already conveys strong feelings of magicalness to a C programmer.  It's really just a
       mnemonic device to remind ourselves that this field is special and not to be used as a
       public data member in the same way that NAME, AGE, and PEERS are.  (Because we've been
       developing this code under the strict pragma, prior to perl version 5.004 we'll have to
       quote the field name.)

	   sub new {
	       my $class = shift;
	       my $self  = {};
	       $self->{NAME}	 = undef;
	       $self->{AGE}	 = undef;
	       $self->{PEERS}	 = [];
	       # "private" data
	       $self->{"_CENSUS"} = \$Census;
	       bless ($self, $class);
	       ++ ${ $self->{"_CENSUS"} };
	       return $self;

	   sub population {
	       my $self = shift;
	       if (ref $self) {
		   return ${ $self->{"_CENSUS"} };
	       } else {
		   return $Census;

	   sub DESTROY {
	       my $self = shift;
	       -- ${ $self->{"_CENSUS"} };

       Debugging Methods

       It's common for a class to have a debugging mechanism.  For example, you might want to see
       when objects are created or destroyed.  To do that, add a debugging variable as a file-
       scoped lexical.	For this, we'll pull in the standard Carp module to emit our warnings and
       fatal messages.	That way messages will come out with the caller's filename and line num-
       ber instead of our own; if we wanted them to be from our own perspective, we'd just use
       die() and warn() directly instead of croak() and carp() respectively.

	   use Carp;
	   my $Debugging = 0;

       Now add a new class method to access the variable.

	   sub debug {
	       my $class = shift;
	       if (ref $class)	{ confess "Class method called as object method" }
	       unless (@_ == 1) { confess "usage: CLASSNAME->debug(level)" }
	       $Debugging = shift;

       Now fix up DESTROY to murmur a bit as the moribund object expires:

	   sub DESTROY {
	       my $self = shift;
	       if ($Debugging) { carp "Destroying $self " . $self->name }
	       -- ${ $self->{"_CENSUS"} };

       One could conceivably make a per-object debug state.  That way you could call both of

	   Person->debug(1);   # entire class
	   $him->debug(1);     # just this object

       To do so, we need our debugging method to be a "bimodal" one, one that works on both
       classes and objects.  Therefore, adjust the debug() and DESTROY methods as follows:

	   sub debug {
	       my $self = shift;
	       confess "usage: thing->debug(level)"    unless @_ == 1;
	       my $level = shift;
	       if (ref($self))	{
		   $self->{"_DEBUG"} = $level;	       # just myself
	       } else {
		   $Debugging	     = $level;	       # whole class

	   sub DESTROY {
	       my $self = shift;
	       if ($Debugging || $self->{"_DEBUG"}) {
		   carp "Destroying $self " . $self->name;
	       -- ${ $self->{"_CENSUS"} };

       What happens if a derived class (which we'll call Employee) inherits methods from this
       Person base class?  Then "Employee->debug()", when called as a class method, manipulates
       $Person::Debugging not $Employee::Debugging.

       Class Destructors

       The object destructor handles the death of each distinct object.  But sometimes you want a
       bit of cleanup when the entire class is shut down, which currently only happens when the
       program exits.  To make such a class destructor, create a function in that class's package
       named END.  This works just like the END function in traditional modules, meaning that it
       gets called whenever your program exits unless it execs or dies of an uncaught signal.
       For example,

	   sub END {
	       if ($Debugging) {
		   print "All persons are going away now.\n";

       When the program exits, all the class destructors (END functions) are be called in the
       opposite order that they were loaded in (LIFO order).

       Documenting the Interface

       And there you have it: we've just shown you the implementation of this Person class.  Its
       interface would be its documentation.  Usually this means putting it in pod ("plain old
       documentation") format right there in the same file.  In our Person example, we would
       place the following docs anywhere in the Person.pm file.  Even though it looks mostly like
       code, it's not.	It's embedded documentation such as would be used by the pod2man,
       pod2html, or pod2text programs.	The Perl compiler ignores pods entirely, just as the
       translators ignore code.  Here's an example of some pods describing the informal inter-

	   =head1 NAME

	   Person - class to implement people

	   =head1 SYNOPSIS

	    use Person;

	    # class methods #
	    $ob    = Person->new;
	    $count = Person->population;

	    # object data methods #

	    ### get versions ###
		$who   = $ob->name;
		$years = $ob->age;
		@pals  = $ob->peers;

	    ### set versions ###
		$ob->peers( "Norbert", "Rhys", "Phineas" );

	    # other object methods #

	    $phrase = $ob->exclaim;

	   =head1 DESCRIPTION

	   The Person class implements dah dee dah dee dah....

       That's all there is to the matter of interface versus implementation.  A programmer who
       opens up the module and plays around with all the private little shiny bits that were
       safely locked up behind the interface contract has voided the warranty, and you shouldn't
       worry about their fate.

       Suppose you later want to change the class to implement better names.  Perhaps you'd like
       to support both given names (called Christian names, irrespective of one's religion) and
       family names (called surnames), plus nicknames and titles.  If users of your Person class
       have been properly accessing it through its documented interface, then you can easily
       change the underlying implementation.  If they haven't, then they lose and it's their
       fault for breaking the contract and voiding their warranty.

       To do this, we'll make another class, this one called Fullname.	What's the Fullname class
       look like?  To answer that question, you have to first figure out how you want to use it.
       How about we use it this way:

	   $him = Person->new();
	   printf "His normal name is %s\n", $him->name;
	   printf "But his real name is %s\n", $him->fullname->as_string;

       Ok.  To do this, we'll change Person::new() so that it supports a full name field this

	   sub new {
	       my $class = shift;
	       my $self  = {};
	       $self->{FULLNAME} = Fullname->new();
	       $self->{AGE}	 = undef;
	       $self->{PEERS}	 = [];
	       $self->{"_CENSUS"} = \$Census;
	       bless ($self, $class);
	       ++ ${ $self->{"_CENSUS"} };
	       return $self;

	   sub fullname {
	       my $self = shift;
	       return $self->{FULLNAME};

       Then to support old code, define Person::name() this way:

	   sub name {
	       my $self = shift;
	       return $self->{FULLNAME}->nickname(@_)
		 ||   $self->{FULLNAME}->christian(@_);

       Here's the Fullname class.  We'll use the same technique of using a hash reference to hold
       data fields, and methods by the appropriate name to access them:

	   package Fullname;
	   use strict;

	   sub new {
	       my $class = shift;
	       my $self  = {
		   TITLE       => undef,
		   CHRISTIAN   => undef,
		   SURNAME     => undef,
		   NICK        => undef,
	       bless ($self, $class);
	       return $self;

	   sub christian {
	       my $self = shift;
	       if (@_) { $self->{CHRISTIAN} = shift }
	       return $self->{CHRISTIAN};

	   sub surname {
	       my $self = shift;
	       if (@_) { $self->{SURNAME} = shift }
	       return $self->{SURNAME};

	   sub nickname {
	       my $self = shift;
	       if (@_) { $self->{NICK} = shift }
	       return $self->{NICK};

	   sub title {
	       my $self = shift;
	       if (@_) { $self->{TITLE} = shift }
	       return $self->{TITLE};

	   sub as_string {
	       my $self = shift;
	       my $name = join(" ", @$self{'CHRISTIAN', 'SURNAME'});
	       if ($self->{TITLE}) {
		   $name = $self->{TITLE} . " " . $name;
	       return $name;


       Finally, here's the test program:

	   #!/usr/bin/perl -w
	   use strict;
	   use Person;
	   sub END { show_census() }

	   sub show_census ()  {
	       printf "Current population: %d\n", Person->population;



	   my $him = Person->new();


	   printf "%s is really %s.\n", $him->name, $him->fullname->as_string;
	   printf "%s's age: %d.\n", $him->name, $him->age;
	   printf "%s's age: %d.\n", $him->name, $him->age;


       Object-oriented programming systems all support some notion of inheritance.  Inheritance
       means allowing one class to piggy-back on top of another one so you don't have to write
       the same code again and again.  It's about software reuse, and therefore related to Lazi-
       ness, the principal virtue of a programmer.  (The import/export mechanisms in traditional
       modules are also a form of code reuse, but a simpler one than the true inheritance that
       you find in object modules.)

       Sometimes the syntax of inheritance is built into the core of the language, and sometimes
       it's not.  Perl has no special syntax for specifying the class (or classes) to inherit
       from.  Instead, it's all strictly in the semantics.  Each package can have a variable
       called @ISA, which governs (method) inheritance.  If you try to call a method on an object
       or class, and that method is not found in that object's package, Perl then looks to @ISA
       for other packages to go looking through in search of the missing method.

       Like the special per-package variables recognized by Exporter (such as @EXPORT,
       @EXPORT_OK, @EXPORT_FAIL, %EXPORT_TAGS, and $VERSION), the @ISA array must be a package-
       scoped global and not a file-scoped lexical created via my().  Most classes have just one
       item in their @ISA array.  In this case, we have what's called "single inheritance", or SI
       for short.

       Consider this class:

	   package Employee;
	   use Person;
	   @ISA = ("Person");

       Not a lot to it, eh?  All it's doing so far is loading in another class and stating that
       this one will inherit methods from that other class if need be.	We have given it none of
       its own methods.  We rely upon an Employee to behave just like a Person.

       Setting up an empty class like this is called the "empty subclass test"; that is, making a
       derived class that does nothing but inherit from a base class.  If the original base class
       has been designed properly, then the new derived class can be used as a drop-in replace-
       ment for the old one.  This means you should be able to write a program like this:

	   use Employee;
	   my $empl = Employee->new();
	   printf "%s is age %d.\n", $empl->name, $empl->age;

       By proper design, we mean always using the two-argument form of bless(), avoiding direct
       access of global data, and not exporting anything.  If you look back at the Person::new()
       function we defined above, we were careful to do that.  There's a bit of package data used
       in the constructor, but the reference to this is stored on the object itself and all other
       methods access package data via that reference, so we should be ok.

       What do we mean by the Person::new() function -- isn't that actually a method?  Well, in
       principle, yes.	A method is just a function that expects as its first argument a class
       name (package) or object (blessed reference).   Person::new() is the function that both
       the "Person->new()" method and the "Employee->new()" method end up calling.  Understand
       that while a method call looks a lot like a function call, they aren't really quite the
       same, and if you treat them as the same, you'll very soon be left with nothing but broken
       programs.  First, the actual underlying calling conventions are different: method calls
       get an extra argument.  Second, function calls don't do inheritance, but methods do.

	       Method Call	       Resulting Function Call
	       -----------	       ------------------------
	       Person->new()	       Person::new("Person")
	       Employee->new()	       Person::new("Employee")

       So don't use function calls when you mean to call a method.

       If an employee is just a Person, that's not all too very interesting.  So let's add some
       other methods.  We'll give our employee data fields to access their salary, their employee
       ID, and their start date.

       If you're getting a little tired of creating all these nearly identical methods just to
       get at the object's data, do not despair.  Later, we'll describe several different conve-
       nience mechanisms for shortening this up.  Meanwhile, here's the straight-forward way:

	   sub salary {
	       my $self = shift;
	       if (@_) { $self->{SALARY} = shift }
	       return $self->{SALARY};

	   sub id_number {
	       my $self = shift;
	       if (@_) { $self->{ID} = shift }
	       return $self->{ID};

	   sub start_date {
	       my $self = shift;
	       if (@_) { $self->{START_DATE} = shift }
	       return $self->{START_DATE};

       Overridden Methods

       What happens when both a derived class and its base class have the same method defined?
       Well, then you get the derived class's version of that method.  For example, let's say
       that we want the peers() method called on an employee to act a bit differently.	Instead
       of just returning the list of peer names, let's return slightly different strings.  So
       doing this:

	   $empl->peers("Peter", "Paul", "Mary");
	   printf "His peers are: %s\n", join(", ", $empl->peers);

       will produce:


       To do this, merely add this definition into the Employee.pm file:

	   sub peers {
	       my $self = shift;
	       if (@_) { @{ $self->{PEERS} } = @_ }
	       return map { "PEON=\U$_" } @{ $self->{PEERS} };

       There, we've just demonstrated the high-falutin' concept known in certain circles as poly-
       morphism.  We've taken on the form and behaviour of an existing object, and then we've
       altered it to suit our own purposes.  This is a form of Laziness.  (Getting polymorphed is
       also what happens when the wizard decides you'd look better as a frog.)

       Every now and then you'll want to have a method call trigger both its derived class (also
       known as "subclass") version as well as its base class (also known as "superclass") ver-
       sion.  In practice, constructors and destructors are likely to want to do this, and it
       probably also makes sense in the debug() method we showed previously.

       To do this, add this to Employee.pm:

	   use Carp;
	   my $Debugging = 0;

	   sub debug {
	       my $self = shift;
	       confess "usage: thing->debug(level)"    unless @_ == 1;
	       my $level = shift;
	       if (ref($self))	{
		   $self->{"_DEBUG"} = $level;
	       } else {
		   $Debugging = $level; 	   # whole class
	       Person::debug($self, $Debugging);   # don't really do this

       As you see, we turn around and call the Person package's debug() function.  But this is
       far too fragile for good design.  What if Person doesn't have a debug() function, but is
       inheriting its debug() method from elsewhere?  It would have been slightly better to say


       But even that's got too much hard-coded.  It's somewhat better to say


       Which is a funny way to say to start looking for a debug() method up in Person.	This
       strategy is more often seen on overridden object methods than on overridden class methods.

       There is still something a bit off here.  We've hard-coded our superclass's name.  This in
       particular is bad if you change which classes you inherit from, or add others.  Fortu-
       nately, the pseudoclass SUPER comes to the rescue here.


       This way it starts looking in my class's @ISA.  This only makes sense from within a method
       call, though.  Don't try to access anything in SUPER:: from anywhere else, because it
       doesn't exist outside an overridden method call. Note that "SUPER" refers to the super-
       class of the current package, not to the superclass of $self.

       Things are getting a bit complicated here.  Have we done anything we shouldn't?	As
       before, one way to test whether we're designing a decent class is via the empty subclass
       test.  Since we already have an Employee class that we're trying to check, we'd better get
       a new empty subclass that can derive from Employee.  Here's one:

	   package Boss;
	   use Employee;	# :-)
	   @ISA = qw(Employee);

       And here's the test program:

	   #!/usr/bin/perl -w
	   use strict;
	   use Boss;

	   my $boss = Boss->new();

	   $boss->fullname->surname("Pichon Alvarez");
	   $boss->fullname->christian("Federico Jesus");

	   $boss->peers("Frank", "Felipe", "Faust");

	   printf "%s is age %d.\n", $boss->fullname->as_string, $boss->age;
	   printf "His peers are: %s\n", join(", ", $boss->peers);

       Running it, we see that we're still ok.	If you'd like to dump out your object in a nice
       format, somewhat like the way the 'x' command works in the debugger, you could use the
       Data::Dumper module from CPAN this way:

	   use Data::Dumper;
	   print "Here's the boss:\n";
	   print Dumper($boss);

       Which shows us something like this:

	   Here's the boss:
	   $VAR1 = bless( {
		_CENSUS => \1,
		FULLNAME => bless( {
				     TITLE => 'Don',
				     SURNAME => 'Pichon Alvarez',
				     NICK => 'Fred',
				     CHRISTIAN => 'Federico Jesus'
				   }, 'Fullname' ),
		AGE => 47,
		PEERS => [
	      }, 'Boss' );

       Hm.... something's missing there.  What about the salary, start date, and ID fields?
       Well, we never set them to anything, even undef, so they don't show up in the hash's keys.
       The Employee class has no new() method of its own, and the new() method in Person doesn't
       know about Employees.  (Nor should it: proper OO design dictates that a subclass be
       allowed to know about its immediate superclass, but never vice-versa.)  So let's fix up
       Employee::new() this way:

	   sub new {
	       my $class = shift;
	       my $self  = $class->SUPER::new();
	       $self->{SALARY}	      = undef;
	       $self->{ID}	      = undef;
	       $self->{START_DATE}    = undef;
	       bless ($self, $class);	       # reconsecrate
	       return $self;

       Now if you dump out an Employee or Boss object, you'll find that new fields show up there

       Multiple Inheritance

       Ok, at the risk of confusing beginners and annoying OO gurus, it's time to confess that
       Perl's object system includes that controversial notion known as multiple inheritance, or
       MI for short.  All this means is that rather than having just one parent class who in turn
       might itself have a parent class, etc., that you can directly inherit from two or more
       parents.  It's true that some uses of MI can get you into trouble, although hopefully not
       quite so much trouble with Perl as with dubiously-OO languages like C++.

       The way it works is actually pretty simple: just put more than one package name in your
       @ISA array.  When it comes time for Perl to go finding methods for your object, it looks
       at each of these packages in order.  Well, kinda.  It's actually a fully recursive, depth-
       first order.  Consider a bunch of @ISA arrays like this:

	   @First::ISA	  = qw( Alpha );
	   @Second::ISA   = qw( Beta );
	   @Third::ISA	  = qw( First Second );

       If you have an object of class Third:

	   my $ob = Third->new();

       How do we find a spin() method (or a new() method for that matter)?  Because the search is
       depth-first, classes will be looked up in the following order: Third, First, Alpha, Sec-
       ond, and Beta.

       In practice, few class modules have been seen that actually make use of MI.  One nearly
       always chooses simple containership of one class within another over MI.  That's why our
       Person object contained a Fullname object.  That doesn't mean it was one.

       However, there is one particular area where MI in Perl is rampant: borrowing another
       class's class methods.  This is rather common, especially with some bundled "objectless"
       classes, like Exporter, DynaLoader, AutoLoader, and SelfLoader.	These classes do not pro-
       vide constructors; they exist only so you may inherit their class methods.  (It's not
       entirely clear why inheritance was done here rather than traditional module importation.)

       For example, here is the POSIX module's @ISA:

	   package POSIX;
	   @ISA = qw(Exporter DynaLoader);

       The POSIX module isn't really an object module, but then, neither are Exporter or
       DynaLoader.  They're just lending their classes' behaviours to POSIX.

       Why don't people use MI for object methods much?  One reason is that it can have compli-
       cated side-effects.  For one thing, your inheritance graph (no longer a tree) might con-
       verge back to the same base class.  Although Perl guards against recursive inheritance,
       merely having parents who are related to each other via a common ancestor, incestuous
       though it sounds, is not forbidden.  What if in our Third class shown above we wanted its
       new() method to also call both overridden constructors in its two parent classes?  The
       SUPER notation would only find the first one.  Also, what about if the Alpha and Beta
       classes both had a common ancestor, like Nought?  If you kept climbing up the inheritance
       tree calling overridden methods, you'd end up calling Nought::new() twice, which might
       well be a bad idea.

       UNIVERSAL: The Root of All Objects

       Wouldn't it be convenient if all objects were rooted at some ultimate base class?  That
       way you could give every object common methods without having to go and add it to each and
       every @ISA.  Well, it turns out that you can.  You don't see it, but Perl tacitly and
       irrevocably assumes that there's an extra element at the end of @ISA: the class UNIVERSAL.
       In version 5.003, there were no predefined methods there, but you could put whatever you
       felt like into it.

       However, as of version 5.004 (or some subversive releases, like 5.003_08), UNIVERSAL has
       some methods in it already.  These are builtin to your Perl binary, so they don't take any
       extra time to load.  Predefined methods include isa(), can(), and VERSION().  isa() tells
       you whether an object or class "is" another one without having to traverse the hierarchy

	  $has_io = $fd->isa("IO::Handle");
	  $itza_handle = IO::Socket->isa("IO::Handle");

       The can() method, called against that object or class, reports back whether its string
       argument is a callable method name in that class.  In fact, it gives you back a function
       reference to that method:

	  $his_print_method = $obj->can('as_string');

       Finally, the VERSION method checks whether the class (or the object's class) has a package
       global called $VERSION that's high enough, as in:

	   $his_vers = $ob->VERSION();

       However, we don't usually call VERSION ourselves.  (Remember that an all uppercase func-
       tion name is a Perl convention that indicates that the function will be automatically used
       by Perl in some way.)  In this case, it happens when you say

	   use Some_Module 3.0;

       If you wanted to add version checking to your Person class explained above, just add this
       to Person.pm:

	   our $VERSION = '1.1';

       and then in Employee.pm you can say

	   use Person 1.1;

       And it would make sure that you have at least that version number or higher available.
       This is not the same as loading in that exact version number.  No mechanism currently
       exists for concurrent installation of multiple versions of a module.  Lamentably.

       Deeper UNIVERSAL details

       It is also valid (though perhaps unwise in most cases) to put other packages' names in
       @UNIVERSAL::ISA.  These packages will also be implicitly inherited by all classes, just as
       UNIVERSAL itself is.  However, neither UNIVERSAL nor any of its parents from the @ISA tree
       are explicit base classes of all objects.  To clarify, given the following:


	   sub special_method { return "123" }

	   package Foo;
	   sub normal_method { return "321" }

       Calling Foo->special_method() will return "123", but calling Foo->isa('REALLYUNIVERSAL')
       or Foo->isa('UNIVERSAL') will return false.

Alternate Object Representations
       Nothing requires objects to be implemented as hash references.  An object can be any sort
       of reference so long as its referent has been suitably blessed.	That means scalar, array,
       and code references are also fair game.

       A scalar would work if the object has only one datum to hold.  An array would work for
       most cases, but makes inheritance a bit dodgy because you have to invent new indices for
       the derived classes.

       Arrays as Objects

       If the user of your class honors the contract and sticks to the advertised interface, then
       you can change its underlying interface if you feel like it.  Here's another implementa-
       tion that conforms to the same interface specification.	This time we'll use an array ref-
       erence instead of a hash reference to represent the object.

	   package Person;
	   use strict;

	   my($NAME, $AGE, $PEERS) = ( 0 .. 2 );

	   ## the object constructor (array version) ##
	   sub new {
	       my $self = [];
	       $self->[$NAME]	= undef;  # this is unnecessary
	       $self->[$AGE]	= undef;  # as is this
	       $self->[$PEERS]	= [];	  # but this isn't, really
	       return $self;

	   sub name {
	       my $self = shift;
	       if (@_) { $self->[$NAME] = shift }
	       return $self->[$NAME];

	   sub age {
	       my $self = shift;
	       if (@_) { $self->[$AGE] = shift }
	       return $self->[$AGE];

	   sub peers {
	       my $self = shift;
	       if (@_) { @{ $self->[$PEERS] } = @_ }
	       return @{ $self->[$PEERS] };

	   1;  # so the require or use succeeds

       You might guess that the array access would be a lot faster than the hash access, but
       they're actually comparable.  The array is a little bit faster, but not more than ten or
       fifteen percent, even when you replace the variables above like $AGE with literal numbers,
       like 1.	A bigger difference between the two approaches can be found in memory use.  A
       hash representation takes up more memory than an array representation because you have to
       allocate memory for the keys as well as for the values.	However, it really isn't that
       bad, especially since as of version 5.004, memory is only allocated once for a given hash
       key, no matter how many hashes have that key.  It's expected that sometime in the future,
       even these differences will fade into obscurity as more efficient underlying representa-
       tions are devised.

       Still, the tiny edge in speed (and somewhat larger one in memory) is enough to make some
       programmers choose an array representation for simple classes.  There's still a little
       problem with scalability, though, because later in life when you feel like creating sub-
       classes, you'll find that hashes just work out better.

       Closures as Objects

       Using a code reference to represent an object offers some fascinating possibilities.  We
       can create a new anonymous function (closure) who alone in all the world can see the
       object's data.  This is because we put the data into an anonymous hash that's lexically
       visible only to the closure we create, bless, and return as the object.	This object's
       methods turn around and call the closure as a regular subroutine call, passing it the
       field we want to affect.  (Yes, the double-function call is slow, but if you wanted fast,
       you wouldn't be using objects at all, eh? :-)

       Use would be similar to before:

	   use Person;
	   $him = Person->new();
	   $him->peers( [ "Norbert", "Rhys", "Phineas" ] );
	   printf "%s is %d years old.\n", $him->name, $him->age;
	   print "His peers are: ", join(", ", @{$him->peers}), "\n";

       but the implementation would be radically, perhaps even sublimely different:

	   package Person;

	   sub new {
		my $class  = shift;
		my $self = {
		   NAME  => undef,
		   AGE	 => undef,
		   PEERS => [],
		my $closure = sub {
		   my $field = shift;
		   if (@_) { $self->{$field} = shift }
		   return    $self->{$field};
	       bless($closure, $class);
	       return $closure;

	   sub name   { &{ $_[0] }("NAME",  @_[ 1 .. $#_ ] ) }
	   sub age    { &{ $_[0] }("AGE",   @_[ 1 .. $#_ ] ) }
	   sub peers  { &{ $_[0] }("PEERS", @_[ 1 .. $#_ ] ) }


       Because this object is hidden behind a code reference, it's probably a bit mysterious to
       those whose background is more firmly rooted in standard procedural or object-based pro-
       gramming languages than in functional programming languages whence closures derive.  The
       object created and returned by the new() method is itself not a data reference as we've
       seen before.  It's an anonymous code reference that has within it access to a specific
       version (lexical binding and instantiation) of the object's data, which are stored in the
       private variable $self.	Although this is the same function each time, it contains a dif-
       ferent version of $self.

       When a method like "$him->name("Jason")" is called, its implicit zeroth argument is the
       invoking object--just as it is with all method calls.  But in this case, it's our code
       reference (something like a function pointer in C++, but with deep binding of lexical
       variables).  There's not a lot to be done with a code reference beyond calling it, so
       that's just what we do when we say "&{$_[0]}".  This is just a regular function call, not
       a method call.  The initial argument is the string "NAME", and any remaining arguments are
       whatever had been passed to the method itself.

       Once we're executing inside the closure that had been created in new(), the $self hash
       reference suddenly becomes visible.  The closure grabs its first argument ("NAME" in this
       case because that's what the name() method passed it), and uses that string to subscript
       into the private hash hidden in its unique version of $self.

       Nothing under the sun will allow anyone outside the executing method to be able to get at
       this hidden data.  Well, nearly nothing.  You could single step through the program using
       the debugger and find out the pieces while you're in the method, but everyone else is out
       of luck.

       There, if that doesn't excite the Scheme folks, then I just don't know what will.  Trans-
       lation of this technique into C++, Java, or any other braindead-static language is left as
       a futile exercise for aficionados of those camps.

       You could even add a bit of nosiness via the caller() function and make the closure refuse
       to operate unless called via its own package.  This would no doubt satisfy certain fastid-
       ious concerns of programming police and related puritans.

       If you were wondering when Hubris, the third principle virtue of a programmer, would come
       into play, here you have it. (More seriously, Hubris is just the pride in craftsmanship
       that comes from having written a sound bit of well-designed code.)

AUTOLOAD: Proxy Methods
       Autoloading is a way to intercept calls to undefined methods.  An autoload routine may
       choose to create a new function on the fly, either loaded from disk or perhaps just
       eval()ed right there.  This define-on-the-fly strategy is why it's called autoloading.

       But that's only one possible approach.  Another one is to just have the autoloaded method
       itself directly provide the requested service.  When used in this way, you may think of
       autoloaded methods as "proxy" methods.

       When Perl tries to call an undefined function in a particular package and that function is
       not defined, it looks for a function in that same package called AUTOLOAD.  If one exists,
       it's called with the same arguments as the original function would have had.  The fully-
       qualified name of the function is stored in that package's global variable $AUTOLOAD.
       Once called, the function can do anything it would like, including defining a new function
       by the right name, and then doing a really fancy kind of "goto" right to it, erasing
       itself from the call stack.

       What does this have to do with objects?	After all, we keep talking about functions, not
       methods.  Well, since a method is just a function with an extra argument and some fancier
       semantics about where it's found, we can use autoloading for methods, too.  Perl doesn't
       start looking for an AUTOLOAD method until it has exhausted the recursive hunt up through
       @ISA, though.  Some programmers have even been known to define a UNIVERSAL::AUTOLOAD
       method to trap unresolved method calls to any kind of object.

       Autoloaded Data Methods

       You probably began to get a little suspicious about the duplicated code way back earlier
       when we first showed you the Person class, and then later the Employee class.  Each method
       used to access the hash fields looked virtually identical.  This should have tickled that
       great programming virtue, Impatience, but for the time, we let Laziness win out, and so
       did nothing.  Proxy methods can cure this.

       Instead of writing a new function every time we want a new data field, we'll use the
       autoload mechanism to generate (actually, mimic) methods on the fly.  To verify that we're
       accessing a valid member, we will check against an "_permitted" (pronounced "under-permit-
       ted") field, which is a reference to a file-scoped lexical (like a C file static) hash of
       permitted fields in this record called %fields.	Why the underscore?  For the same reason
       as the _CENSUS field we once used: as a marker that means "for internal use only".

       Here's what the module initialization code and class constructor will look like when tak-
       ing this approach:

	   package Person;
	   use Carp;
	   our $AUTOLOAD;  # it's a package global

	   my %fields = (
	       name	   => undef,
	       age	   => undef,
	       peers	   => undef,

	   sub new {
	       my $class = shift;
	       my $self  = {
		   _permitted => \%fields,
	       bless $self, $class;
	       return $self;

       If we wanted our record to have default values, we could fill those in where current we
       have "undef" in the %fields hash.

       Notice how we saved a reference to our class data on the object itself?	Remember that
       it's important to access class data through the object itself instead of having any method
       reference %fields directly, or else you won't have a decent inheritance.

       The real magic, though, is going to reside in our proxy method, which will handle all
       calls to undefined methods for objects of class Person (or subclasses of Person).  It has
       to be called AUTOLOAD.  Again, it's all caps because it's called for us implicitly by Perl
       itself, not by a user directly.

	   sub AUTOLOAD {
	       my $self = shift;
	       my $type = ref($self)
			   or croak "$self is not an object";

	       my $name = $AUTOLOAD;
	       $name =~ s/.*://;   # strip fully-qualified portion

	       unless (exists $self->{_permitted}->{$name} ) {
		   croak "Can't access `$name' field in class $type";

	       if (@_) {
		   return $self->{$name} = shift;
	       } else {
		   return $self->{$name};

       Pretty nifty, eh?  All we have to do to add new data fields is modify %fields.  No new
       functions need be written.

       I could have avoided the "_permitted" field entirely, but I wanted to demonstrate how to
       store a reference to class data on the object so you wouldn't have to access that class
       data directly from an object method.

       Inherited Autoloaded Data Methods

       But what about inheritance?  Can we define our Employee class similarly?  Yes, so long as
       we're careful enough.

       Here's how to be careful:

	   package Employee;
	   use Person;
	   use strict;
	   our @ISA = qw(Person);

	   my %fields = (
	       id	   => undef,
	       salary	   => undef,

	   sub new {
	       my $class = shift;
	       my $self  = $class->SUPER::new();
	       foreach $element (keys %fields) {
		   $self->{_permitted}->{$element} = $fields{$element};
	       @{$self}{keys %fields} = values %fields;
	       return $self;

       Once we've done this, we don't even need to have an AUTOLOAD function in the Employee
       package, because we'll grab Person's version of that via inheritance, and it will all work
       out just fine.

Metaclassical Tools
       Even though proxy methods can provide a more convenient approach to making more struct-
       like classes than tediously coding up data methods as functions, it still leaves a bit to
       be desired.  For one thing, it means you have to handle bogus calls that you don't mean to
       trap via your proxy.  It also means you have to be quite careful when dealing with inheri-
       tance, as detailed above.

       Perl programmers have responded to this by creating several different class construction
       classes.  These metaclasses are classes that create other classes.  A couple worth looking
       at are Class::Struct and Alias.	These and other related metaclasses can be found in the
       modules directory on CPAN.


       One of the older ones is Class::Struct.	In fact, its syntax and interface were sketched
       out long before perl5 even solidified into a real thing.  What it does is provide you a
       way to "declare" a class as having objects whose fields are of a specific type.	The func-
       tion that does this is called, not surprisingly enough, struct().  Because structures or
       records are not base types in Perl, each time you want to create a class to provide a
       record-like data object, you yourself have to define a new() method, plus separate data-
       access methods for each of that record's fields.  You'll quickly become bored with this
       process.  The Class::Struct::struct() function alleviates this tedium.

       Here's a simple example of using it:

	   use Class::Struct qw(struct);
	   use Jobbie;	# user-defined; see below

	   struct 'Fred' => {
	       one	  => '$',
	       many	  => '@',
	       profession => 'Jobbie',	# does not call Jobbie->new()

	   $ob = Fred->new(profession => Jobbie->new());

	   $ob->many(0, "here");
	   $ob->many(1, "you");
	   $ob->many(2, "go");
	   print "Just set: ", $ob->many(2), "\n";


       You can declare types in the struct to be basic Perl types, or user-defined types
       (classes).  User types will be initialized by calling that class's new() method.

       Take care that the "Jobbie" object is not created automatically by the "Fred" class's
       new() method, so you should specify a "Jobbie" object when you create an instance of

       Here's a real-world example of using struct generation.	Let's say you wanted to override
       Perl's idea of gethostbyname() and gethostbyaddr() so that they would return objects that
       acted like C structures.  We don't care about high-falutin' OO gunk.  All we want is for
       these objects to act like structs in the C sense.

	   use Socket;
	   use Net::hostent;
	   $h = gethostbyname("perl.com");  # object return
	   printf "perl.com's real name is %s, address %s\n",
	       $h->name, inet_ntoa($h->addr);

       Here's how to do this using the Class::Struct module.  The crux is going to be this call:

	   struct 'Net::hostent' => [	       # note bracket
	       name	  => '$',
	       aliases	  => '@',
	       addrtype   => '$',
	       'length'   => '$',
	       addr_list  => '@',

       Which creates object methods of those names and types.  It even creates a new() method for

       We could also have implemented our object this way:

	   struct 'Net::hostent' => {	       # note brace
	       name	  => '$',
	       aliases	  => '@',
	       addrtype   => '$',
	       'length'   => '$',
	       addr_list  => '@',

       and then Class::Struct would have used an anonymous hash as the object type, instead of an
       anonymous array.  The array is faster and smaller, but the hash works out better if you
       eventually want to do inheritance.  Since for this struct-like object we aren't planning
       on inheritance, this time we'll opt for better speed and size over better flexibility.

       Here's the whole implementation:

	   package Net::hostent;
	   use strict;

	   BEGIN {
	       use Exporter   ();
	       our @EXPORT	= qw(gethostbyname gethostbyaddr gethost);
	       our @EXPORT_OK	= qw(
				      $h_name	      @h_aliases
				      $h_addrtype     $h_length
				      @h_addr_list    $h_addr
	       our %EXPORT_TAGS = ( FIELDS => [ @EXPORT_OK, @EXPORT ] );
	   our @EXPORT_OK;

	   # Class::Struct forbids use of @ISA
	   sub import { goto &Exporter::import }

	   use Class::Struct qw(struct);
	   struct 'Net::hostent' => [
	      name	  => '$',
	      aliases	  => '@',
	      addrtype	  => '$',
	      'length'	  => '$',
	      addr_list   => '@',

	   sub addr { shift->addr_list->[0] }

	   sub populate (@) {
	       return unless @_;
	       my $hob = new();  # Class::Struct made this!
	       $h_name	   =	$hob->[0]	       = $_[0];
	       @h_aliases  = @{ $hob->[1] } = split ' ', $_[1];
	       $h_addrtype =	$hob->[2]	       = $_[2];
	       $h_length   =	$hob->[3]	       = $_[3];
	       $h_addr	   =				 $_[4];
	       @h_addr_list = @{ $hob->[4] } =	       @_[ (4 .. $#_) ];
	       return $hob;

	   sub gethostbyname ($)  { populate(CORE::gethostbyname(shift)) }

	   sub gethostbyaddr ($;$) {
	       my ($addr, $addrtype);
	       $addr = shift;
	       require Socket unless @_;
	       $addrtype = @_ ? shift : Socket::AF_INET();
	       populate(CORE::gethostbyaddr($addr, $addrtype))

	   sub gethost($) {
	       if ($_[0] =~ /^\d+(?:\.\d+(?:\.\d+(?:\.\d+)?)?)?$/) {
		  require Socket;
	       } else {


       We've snuck in quite a fair bit of other concepts besides just dynamic class creation,
       like overriding core functions, import/export bits, function prototyping, short-cut func-
       tion call via &whatever, and function replacement with "goto &whatever".  These all mostly
       make sense from the perspective of a traditional module, but as you can see, we can also
       use them in an object module.

       You can look at other object-based, struct-like overrides of core functions in the 5.004
       release of Perl in File::stat, Net::hostent, Net::netent, Net::protoent, Net::servent,
       Time::gmtime, Time::localtime, User::grent, and User::pwent.  These modules have a final
       component that's all lowercase, by convention reserved for compiler pragmas, because they
       affect the compilation and change a builtin function.  They also have the type names that
       a C programmer would most expect.

       Data Members as Variables

       If you're used to C++ objects, then you're accustomed to being able to get at an object's
       data members as simple variables from within a method.  The Alias module provides for
       this, as well as a good bit more, such as the possibility of private methods that the
       object can call but folks outside the class cannot.

       Here's an example of creating a Person using the Alias module.  When you update these mag-
       ical instance variables, you automatically update value fields in the hash.  Convenient,

	   package Person;

	   # this is the same as before...
	   sub new {
		my $class = shift;
		my $self = {
		   NAME  => undef,
		   AGE	 => undef,
		   PEERS => [],
	       bless($self, $class);
	       return $self;

	   use Alias qw(attr);
	   our ($NAME, $AGE, $PEERS);

	   sub name {
	       my $self = attr shift;
	       if (@_) { $NAME = shift; }
	       return	 $NAME;

	   sub age {
	       my $self = attr shift;
	       if (@_) { $AGE = shift; }
	       return	 $AGE;

	   sub peers {
	       my $self = attr shift;
	       if (@_) { @PEERS = @_; }
	       return	 @PEERS;

	   sub exclaim {
	       my $self = attr shift;
	       return sprintf "Hi, I'm %s, age %d, working with %s",
		   $NAME, $AGE, join(", ", @PEERS);

	   sub happy_birthday {
	       my $self = attr shift;
	       return ++$AGE;

       The need for the "our" declaration is because what Alias does is play with package globals
       with the same name as the fields.  To use globals while "use strict" is in effect, you
       have to predeclare them.  These package variables are localized to the block enclosing the
       attr() call just as if you'd used a local() on them.  However, that means that they're
       still considered global variables with temporary values, just as with any other local().

       It would be nice to combine Alias with something like Class::Struct or Class::MethodMaker.

       Object Terminology

       In the various OO literature, it seems that a lot of different words are used to describe
       only a few different concepts.  If you're not already an object programmer, then you don't
       need to worry about all these fancy words.  But if you are, then you might like to know
       how to get at the same concepts in Perl.

       For example, it's common to call an object an instance of a class and to call those
       objects' methods instance methods.  Data fields peculiar to each object are often called
       instance data or object attributes, and data fields common to all members of that class
       are class data, class attributes, or static data members.

       Also, base class, generic class, and superclass all describe the same notion, whereas
       derived class, specific class, and subclass describe the other related one.

       C++ programmers have static methods and virtual methods, but Perl only has class methods
       and object methods.  Actually, Perl only has methods.  Whether a method gets used as a
       class or object method is by usage only.  You could accidentally call a class method (one
       expecting a string argument) on an object (one expecting a reference), or vice versa.

       From the C++ perspective, all methods in Perl are virtual.  This, by the way, is why they
       are never checked for function prototypes in the argument list as regular builtin and
       user-defined functions can be.

       Because a class is itself something of an object, Perl's classes can be taken as describ-
       ing both a "class as meta-object" (also called object factory) philosophy and the "class
       as type definition" (declaring behaviour, not defining mechanism) idea.	C++ supports the
       latter notion, but not the former.

       The following manpages will doubtless provide more background for this one: perlmod, perl-
       ref, perlobj, perlbot, perltie, and overload.

       perlboot is a kinder, gentler introduction to object-oriented programming.

       perltooc provides more detail on class data.

       Some modules which might prove interesting are Class::Accessor, Class::Class, Class::Con-
       tract, Class::Data::Inheritable, Class::MethodMaker and Tie::SecureHash

       Copyright (c) 1997, 1998 Tom Christiansen All rights reserved.

       This documentation is free; you can redistribute it and/or modify it under the same terms
       as Perl itself.

       Irrespective of its distribution, all code examples in this file are hereby placed into
       the public domain.  You are permitted and encouraged to use this code in your own programs
       for fun or for profit as you see fit.  A simple comment in the code giving credit would be
       courteous but is not required.


       Thanks to Larry Wall, Roderick Schertler, Gurusamy Sarathy, Dean Roehrich, Raphael Man-
       fredi, Brent Halsey, Greg Bacon, Brad Appleton, and many others for their helpful com-

perl v5.8.9				    2007-11-17				      PERLTOOT(1)

All times are GMT -4. The time now is 07:13 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password