diff options
Diffstat (limited to 'Master/tlpkg/tlperl.straw/lib/pods/perlboot.pod')
-rwxr-xr-x | Master/tlpkg/tlperl.straw/lib/pods/perlboot.pod | 884 |
1 files changed, 884 insertions, 0 deletions
diff --git a/Master/tlpkg/tlperl.straw/lib/pods/perlboot.pod b/Master/tlpkg/tlperl.straw/lib/pods/perlboot.pod new file mode 100755 index 00000000000..cf8e51843ae --- /dev/null +++ b/Master/tlpkg/tlperl.straw/lib/pods/perlboot.pod @@ -0,0 +1,884 @@ +=head1 NAME + +perlboot - Beginner's Object-Oriented Tutorial + +=head1 DESCRIPTION + +If you're not familiar with objects from other languages, some of the +other Perl object documentation may be a little daunting, such as +L<perlobj>, a basic reference in using objects, and L<perltoot>, which +introduces readers to the peculiarities of Perl's object system in a +tutorial way. + +So, let's take a different approach, presuming no prior object +experience. It helps if you know about subroutines (L<perlsub>), +references (L<perlref> et. seq.), and packages (L<perlmod>), so become +familiar with those first if you haven't already. + +=head2 If we could talk to the animals... + +Let's let the animals talk for a moment: + + sub Cow::speak { + print "a Cow goes moooo!\n"; + } + sub Horse::speak { + print "a Horse goes neigh!\n"; + } + sub Sheep::speak { + print "a Sheep goes baaaah!\n"; + } + + Cow::speak; + Horse::speak; + Sheep::speak; + +This results in: + + a Cow goes moooo! + a Horse goes neigh! + a Sheep goes baaaah! + +Nothing spectacular here. Simple subroutines, albeit from separate +packages, and called using the full package name. So let's create +an entire pasture: + + # Cow::speak, Horse::speak, Sheep::speak as before + @pasture = qw(Cow Cow Horse Sheep Sheep); + foreach $animal (@pasture) { + &{$animal."::speak"}; + } + +This results in: + + a Cow goes moooo! + a Cow goes moooo! + a Horse goes neigh! + a Sheep goes baaaah! + a Sheep goes baaaah! + +Wow. That symbolic coderef de-referencing there is pretty nasty. +We're counting on C<no strict refs> mode, certainly not recommended +for larger programs. And why was that necessary? Because the name of +the package seems to be inseparable from the name of the subroutine we +want to invoke within that package. + +Or is it? + +=head2 Introducing the method invocation arrow + +For now, let's say that C<< Class->method >> invokes subroutine +C<method> in package C<Class>. (Here, "Class" is used in its +"category" meaning, not its "scholastic" meaning.) That's not +completely accurate, but we'll do this one step at a time. Now let's +use it like so: + + # Cow::speak, Horse::speak, Sheep::speak as before + Cow->speak; + Horse->speak; + Sheep->speak; + +And once again, this results in: + + a Cow goes moooo! + a Horse goes neigh! + a Sheep goes baaaah! + +That's not fun yet. Same number of characters, all constant, no +variables. But yet, the parts are separable now. Watch: + + $a = "Cow"; + $a->speak; # invokes Cow->speak + +Ahh! Now that the package name has been parted from the subroutine +name, we can use a variable package name. And this time, we've got +something that works even when C<use strict refs> is enabled. + +=head2 Invoking a barnyard + +Let's take that new arrow invocation and put it back in the barnyard +example: + + sub Cow::speak { + print "a Cow goes moooo!\n"; + } + sub Horse::speak { + print "a Horse goes neigh!\n"; + } + sub Sheep::speak { + print "a Sheep goes baaaah!\n"; + } + + @pasture = qw(Cow Cow Horse Sheep Sheep); + foreach $animal (@pasture) { + $animal->speak; + } + +There! Now we have the animals all talking, and safely at that, +without the use of symbolic coderefs. + +But look at all that common code. Each of the C<speak> routines has a +similar structure: a C<print> operator and a string that contains +common text, except for two of the words. It'd be nice if we could +factor out the commonality, in case we decide later to change it all +to C<says> instead of C<goes>. + +And we actually have a way of doing that without much fuss, but we +have to hear a bit more about what the method invocation arrow is +actually doing for us. + +=head2 The extra parameter of method invocation + +The invocation of: + + Class->method(@args) + +attempts to invoke subroutine C<Class::method> as: + + Class::method("Class", @args); + +(If the subroutine can't be found, "inheritance" kicks in, but we'll +get to that later.) This means that we get the class name as the +first parameter (the only parameter, if no arguments are given). So +we can rewrite the C<Sheep> speaking subroutine as: + + sub Sheep::speak { + my $class = shift; + print "a $class goes baaaah!\n"; + } + +And the other two animals come out similarly: + + sub Cow::speak { + my $class = shift; + print "a $class goes moooo!\n"; + } + sub Horse::speak { + my $class = shift; + print "a $class goes neigh!\n"; + } + +In each case, C<$class> will get the value appropriate for that +subroutine. But once again, we have a lot of similar structure. Can +we factor that out even further? Yes, by calling another method in +the same class. + +=head2 Calling a second method to simplify things + +Let's call out from C<speak> to a helper method called C<sound>. +This method provides the constant text for the sound itself. + + { package Cow; + sub sound { "moooo" } + sub speak { + my $class = shift; + print "a $class goes ", $class->sound, "!\n"; + } + } + +Now, when we call C<< Cow->speak >>, we get a C<$class> of C<Cow> in +C<speak>. This in turn selects the C<< Cow->sound >> method, which +returns C<moooo>. But how different would this be for the C<Horse>? + + { package Horse; + sub sound { "neigh" } + sub speak { + my $class = shift; + print "a $class goes ", $class->sound, "!\n"; + } + } + +Only the name of the package and the specific sound change. So can we +somehow share the definition for C<speak> between the Cow and the +Horse? Yes, with inheritance! + +=head2 Inheriting the windpipes + +We'll define a common subroutine package called C<Animal>, with the +definition for C<speak>: + + { package Animal; + sub speak { + my $class = shift; + print "a $class goes ", $class->sound, "!\n"; + } + } + +Then, for each animal, we say it "inherits" from C<Animal>, along +with the animal-specific sound: + + { package Cow; + @ISA = qw(Animal); + sub sound { "moooo" } + } + +Note the added C<@ISA> array (pronounced "is a"). We'll get to that in a minute. + +But what happens when we invoke C<< Cow->speak >> now? + +First, Perl constructs the argument list. In this case, it's just +C<Cow>. Then Perl looks for C<Cow::speak>. But that's not there, so +Perl checks for the inheritance array C<@Cow::ISA>. It's there, +and contains the single name C<Animal>. + +Perl next checks for C<speak> inside C<Animal> instead, as in +C<Animal::speak>. And that's found, so Perl invokes that subroutine +with the already frozen argument list. + +Inside the C<Animal::speak> subroutine, C<$class> becomes C<Cow> (the +first argument). So when we get to the step of invoking +C<< $class->sound >>, it'll be looking for C<< Cow->sound >>, which +gets it on the first try without looking at C<@ISA>. Success! + +=head2 A few notes about @ISA + +This magical C<@ISA> variable has declared that C<Cow> "is a" C<Animal>. +Note that it's an array, not a simple single value, because on rare +occasions, it makes sense to have more than one parent class searched +for the missing methods. + +If C<Animal> also had an C<@ISA>, then we'd check there too. The +search is recursive, depth-first, left-to-right in each C<@ISA> by +default (see L<mro> for alternatives). Typically, each C<@ISA> has +only one element (multiple elements means multiple inheritance and +multiple headaches), so we get a nice tree of inheritance. + +When we turn on C<use strict>, we'll get complaints on C<@ISA>, since +it's not a variable containing an explicit package name, nor is it a +lexical ("my") variable. We can't make it a lexical variable though +(it has to belong to the package to be found by the inheritance mechanism), +so there's a couple of straightforward ways to handle that. + +The easiest is to just spell the package name out: + + @Cow::ISA = qw(Animal); + +Or declare it as package global variable: + + package Cow; + our @ISA = qw(Animal); + +Or allow it as an implicitly named package variable: + + package Cow; + use vars qw(@ISA); + @ISA = qw(Animal); + +If the C<Animal> class comes from another (object-oriented) module, then +just employ C<use base> to specify that C<Animal> should serve as the basis +for the C<Cow> class: + + package Cow; + use base qw(Animal); + +Now that's pretty darn simple! + +=head2 Overriding the methods + +Let's add a mouse, which can barely be heard: + + # Animal package from before + { package Mouse; + @ISA = qw(Animal); + sub sound { "squeak" } + sub speak { + my $class = shift; + print "a $class goes ", $class->sound, "!\n"; + print "[but you can barely hear it!]\n"; + } + } + + Mouse->speak; + +which results in: + + a Mouse goes squeak! + [but you can barely hear it!] + +Here, C<Mouse> has its own speaking routine, so C<< Mouse->speak >> +doesn't immediately invoke C<< Animal->speak >>. This is known as +"overriding". In fact, we don't even need to say that a C<Mouse> is +an C<Animal> at all, because all of the methods needed for C<speak> are +completely defined for C<Mouse>; this is known as "duck typing": +"If it walks like a duck and quacks like a duck, I would call it a duck" +(James Whitcomb). However, it would probably be beneficial to allow a +closer examination to conclude that a C<Mouse> is indeed an C<Animal>, +so it is actually better to define C<Mouse> with C<Animal> as its base +(that is, it is better to "derive C<Mouse> from C<Animal>"). + +Moreover, this duplication of code could become a maintenance headache +(though code-reuse is not actually a good reason for inheritance; good +design practices dictate that a derived class should be usable wherever +its base class is usable, which might not be the outcome if code-reuse +is the sole criterion for inheritance. Just remember that a C<Mouse> +should always act like an C<Animal>). + +So, let's make C<Mouse> an C<Animal>! + +The obvious solution is to invoke C<Animal::speak> directly: + + # Animal package from before + { package Mouse; + @ISA = qw(Animal); + sub sound { "squeak" } + sub speak { + my $class = shift; + Animal::speak($class); + print "[but you can barely hear it!]\n"; + } + } + +Note that we're using C<Animal::speak>. If we were to invoke +C<< Animal->speak >> instead, the first parameter to C<Animal::speak> +would automatically be C<"Animal"> rather than C<"Mouse">, so that +the call to C<< $class->sound >> in C<Animal::speak> would become +C<< Animal->sound >> rather than C<< Mouse->sound >>. + +Also, without the method arrow C<< -> >>, it becomes necessary to specify +the first parameter to C<Animal::speak> ourselves, which is why C<$class> +is explicitly passed: C<Animal::speak($class)>. + +However, invoking C<Animal::speak> directly is a mess: Firstly, it assumes +that the C<speak> method is a member of the C<Animal> class; what if C<Animal> +actually inherits C<speak> from its own base? Because we are no longer using +C<< -> >> to access C<speak>, the special method look up mechanism wouldn't be +used, so C<speak> wouldn't even be found! + +The second problem is more subtle: C<Animal> is now hardwired into the subroutine +selection. Let's assume that C<Animal::speak> does exist. What happens when, +at a later time, someone expands the class hierarchy by having C<Mouse> +inherit from C<Mus> instead of C<Animal>. Unless the invocation of C<Animal::speak> +is also changed to an invocation of C<Mus::speak>, centuries worth of taxonomical +classification could be obliterated! + +What we have here is a fragile or leaky abstraction; it is the beginning of a +maintenance nightmare. What we need is the ability to search for the right +method wih as few assumptions as possible. + +=head2 Starting the search from a different place + +A I<better> solution is to tell Perl where in the inheritance chain to begin searching +for C<speak>. This can be achieved with a modified version of the method arrow C<< -> >>: + + ClassName->FirstPlaceToLook::method + +So, the improved C<Mouse> class is: + + # same Animal as before + { package Mouse; + # same @ISA, &sound as before + sub speak { + my $class = shift; + $class->Animal::speak; + print "[but you can barely hear it!]\n"; + } + } + +Using this syntax, we start with C<Animal> to find C<speak>, and then +use all of C<Animal>'s inheritance chain if it is not found immediately. +As usual, the first parameter to C<speak> would be C<$class>, so we no +longer need to pass C<$class> explicitly to C<speak>. + +But what about the second problem? We're still hardwiring C<Animal> into +the method lookup. + +=head2 The SUPER way of doing things + +If C<Animal> is replaced with the special placeholder C<SUPER> in that +invocation, then the contents of C<Mouse>'s C<@ISA> are used for the +search, beginning with C<$ISA[0]>. So, all of the problems can be fixed +as follows: + + # same Animal as before + { package Mouse; + # same @ISA, &sound as before + sub speak { + my $class = shift; + $class->SUPER::speak; + print "[but you can barely hear it!]\n"; + } + } + +In general, C<SUPER::speak> means look in the current package's C<@ISA> +for a class that implements C<speak>, and invoke the first one found. +The placeholder is called C<SUPER>, because many other languages refer +to base classes as "I<super>classes", and Perl likes to be eclectic. + +Note that a call such as + + $class->SUPER::method; + +does I<not> look in the C<@ISA> of C<$class> unless C<$class> happens to +be the current package. + +=head2 Let's review... + +So far, we've seen the method arrow syntax: + + Class->method(@args); + +or the equivalent: + + $a = "Class"; + $a->method(@args); + +which constructs an argument list of: + + ("Class", @args) + +and attempts to invoke: + + Class::method("Class", @args); + +However, if C<Class::method> is not found, then C<@Class::ISA> is examined +(recursively) to locate a class (a package) that does indeed contain C<method>, +and that subroutine is invoked instead. + +Using this simple syntax, we have class methods, (multiple) inheritance, +overriding, and extending. Using just what we've seen so far, we've +been able to factor out common code (though that's never a good reason +for inheritance!), and provide a nice way to reuse implementations with +variations. + +Now, what about data? + +=head2 A horse is a horse, of course of course -- or is it? + +Let's start with the code for the C<Animal> class +and the C<Horse> class: + + { package Animal; + sub speak { + my $class = shift; + print "a $class goes ", $class->sound, "!\n"; + } + } + { package Horse; + @ISA = qw(Animal); + sub sound { "neigh" } + } + +This lets us invoke C<< Horse->speak >> to ripple upward to +C<Animal::speak>, calling back to C<Horse::sound> to get the specific +sound, and the output of: + + a Horse goes neigh! + +But all of our Horse objects would have to be absolutely identical. +If we add a subroutine, all horses automatically share it. That's +great for making horses the same, but how do we capture the +distinctions of an individual horse? For example, suppose we want +to give our first horse a name. There's got to be a way to keep its +name separate from the other horses. + +That is to say, we want particular instances of C<Horse> to have +different names. + +In Perl, any reference can be an "instance", so let's start with the +simplest reference that can hold a horse's name: a scalar reference. + + my $name = "Mr. Ed"; + my $horse = \$name; + +So, now C<$horse> is a reference to what will be the instance-specific +data (the name). The final step is to turn this reference into a real +instance of a C<Horse> by using the special operator C<bless>: + + bless $horse, Horse; + +This operator stores information about the package named C<Horse> into +the thing pointed at by the reference. At this point, we say +C<$horse> is an instance of C<Horse>. That is, it's a specific +horse. The reference is otherwise unchanged, and can still be used +with traditional dereferencing operators. + +=head2 Invoking an instance method + +The method arrow can be used on instances, as well as classes (the names +of packages). So, let's get the sound that C<$horse> makes: + + my $noise = $horse->sound("some", "unnecessary", "args"); + +To invoke C<sound>, Perl first notes that C<$horse> is a blessed +reference (and thus an instance). It then constructs an argument +list, as per usual. + +Now for the fun part: Perl takes the class in which the instance was +blessed, in this case C<Horse>, and uses that class to locate the +subroutine. In this case, C<Horse::sound> is found directly (without +using inheritance). In the end, it is as though our initial line were +written as follows: + + my $noise = Horse::sound($horse, "some", "unnecessary", "args"); + +Note that the first parameter here is still the instance, not the name +of the class as before. We'll get C<neigh> as the return value, and +that'll end up as the C<$noise> variable above. + +If Horse::sound had not been found, we'd be wandering up the C<@Horse::ISA> +array, trying to find the method in one of the superclasses. The only +difference between a class method and an instance method is whether the +first parameter is an instance (a blessed reference) or a class name (a +string). + +=head2 Accessing the instance data + +Because we get the instance as the first parameter, we can now access +the instance-specific data. In this case, let's add a way to get at +the name: + + { package Horse; + @ISA = qw(Animal); + sub sound { "neigh" } + sub name { + my $self = shift; + $$self; + } + } + +Inside C<Horse::name>, the C<@_> array contains: + + ($horse, "some", "unnecessary", "args") + +so the C<shift> stores C<$horse> into C<$self>. Then, C<$self> gets +de-referenced with C<$$self> as normal, yielding C<"Mr. Ed">. + +It's traditional to C<shift> the first parameter into a variable named +C<$self> for instance methods and into a variable named C<$class> for +class methods. + +Then, the following line: + + print $horse->name, " says ", $horse->sound, "\n"; + +outputs: + + Mr. Ed says neigh. + +=head2 How to build a horse + +Of course, if we constructed all of our horses by hand, we'd most +likely make mistakes from time to time. We're also violating one of +the properties of object-oriented programming, in that the "inside +guts" of a Horse are visible. That's good if you're a veterinarian, +but not if you just like to own horses. So, let's have the Horse +class handle the details inside a class method: + + { package Horse; + @ISA = qw(Animal); + sub sound { "neigh" } + sub name { + my $self = shift; # instance method, so use $self + $$self; + } + sub named { + my $class = shift; # class method, so use $class + my $name = shift; + bless \$name, $class; + } + } + +Now with the new C<named> method, we can build a horse as follows: + + my $horse = Horse->named("Mr. Ed"); + +Notice we're back to a class method, so the two arguments to +C<Horse::named> are C<Horse> and C<Mr. Ed>. The C<bless> operator +not only blesses C<\$name>, it also returns that reference. + +This C<Horse::named> method is called a "constructor". + +We've called the constructor C<named> here, so that it quickly denotes +the constructor's argument as the name for this particular C<Horse>. +You can use different constructors with different names for different +ways of "giving birth" to the object (like maybe recording its +pedigree or date of birth). However, you'll find that most people +coming to Perl from more limited languages use a single constructor +named C<new>, with various ways of interpreting the arguments to +C<new>. Either style is fine, as long as you document your particular +way of giving birth to an object. (And you I<were> going to do that, +right?) + +=head2 Inheriting the constructor + +But was there anything specific to C<Horse> in that method? No. Therefore, +it's also the same recipe for building anything else that inherited from +C<Animal>, so let's put C<name> and C<named> there: + + { package Animal; + sub speak { + my $class = shift; + print "a $class goes ", $class->sound, "!\n"; + } + sub name { + my $self = shift; + $$self; + } + sub named { + my $class = shift; + my $name = shift; + bless \$name, $class; + } + } + { package Horse; + @ISA = qw(Animal); + sub sound { "neigh" } + } + +Ahh, but what happens if we invoke C<speak> on an instance? + + my $horse = Horse->named("Mr. Ed"); + $horse->speak; + +We get a debugging value: + + a Horse=SCALAR(0xaca42ac) goes neigh! + +Why? Because the C<Animal::speak> routine is expecting a classname as +its first parameter, not an instance. When the instance is passed in, +we'll end up using a blessed scalar reference as a string, and that +shows up as we saw it just now. + +=head2 Making a method work with either classes or instances + +All we need is for a method to detect if it is being called on a class +or called on an instance. The most straightforward way is with the +C<ref> operator. This returns a string (the classname) when used on a +blessed reference, and an empty string when used on a string (like a +classname). Let's modify the C<name> method first to notice the change: + + sub name { + my $either = shift; + ref $either ? $$either : "Any $either"; + } + +Here, the C<?:> operator comes in handy to select either the +dereference or a derived string. Now we can use this with either an +instance or a class. Note that I've changed the first parameter +holder to C<$either> to show that this is intended: + + my $horse = Horse->named("Mr. Ed"); + print Horse->name, "\n"; # prints "Any Horse\n" + print $horse->name, "\n"; # prints "Mr Ed.\n" + +and now we'll fix C<speak> to use this: + + sub speak { + my $either = shift; + print $either->name, " goes ", $either->sound, "\n"; + } + +And since C<sound> already worked with either a class or an instance, +we're done! + +=head2 Adding parameters to a method + +Let's train our animals to eat: + + { package Animal; + sub named { + my $class = shift; + my $name = shift; + bless \$name, $class; + } + sub name { + my $either = shift; + ref $either ? $$either : "Any $either"; + } + sub speak { + my $either = shift; + print $either->name, " goes ", $either->sound, "\n"; + } + sub eat { + my $either = shift; + my $food = shift; + print $either->name, " eats $food.\n"; + } + } + { package Horse; + @ISA = qw(Animal); + sub sound { "neigh" } + } + { package Sheep; + @ISA = qw(Animal); + sub sound { "baaaah" } + } + +And now try it out: + + my $horse = Horse->named("Mr. Ed"); + $horse->eat("hay"); + Sheep->eat("grass"); + +which prints: + + Mr. Ed eats hay. + Any Sheep eats grass. + +An instance method with parameters gets invoked with the instance, +and then the list of parameters. So that first invocation is like: + + Animal::eat($horse, "hay"); + +=head2 More interesting instances + +What if an instance needs more data? Most interesting instances are +made of many items, each of which can in turn be a reference or even +another object. The easiest way to store these is often in a hash. +The keys of the hash serve as the names of parts of the object (often +called "instance variables" or "member variables"), and the +corresponding values are, well, the values. + +But how do we turn the horse into a hash? Recall that an object was +any blessed reference. We can just as easily make it a blessed hash +reference as a blessed scalar reference, as long as everything that +looks at the reference is changed accordingly. + +Let's make a sheep that has a name and a color: + + my $bad = bless { Name => "Evil", Color => "black" }, Sheep; + +so C<< $bad->{Name} >> has C<Evil>, and C<< $bad->{Color} >> has +C<black>. But we want to make C<< $bad->name >> access the name, and +that's now messed up because it's expecting a scalar reference. Not +to worry, because that's pretty easy to fix up. + +One solution is to override C<Animal::name> and C<Animal::named> by +defining them anew in C<Sheep>, but then any methods added later to +C<Animal> might still mess up, and we'd have to override all of those +too. Therefore, it's never a good idea to define the data layout in a +way that's different from the data layout of the base classes. In fact, +it's a good idea to use blessed hash references in all cases. Also, this +is why it's important to have constructors do the low-level work. So, +let's redefine C<Animal>: + + ## in Animal + sub name { + my $either = shift; + ref $either ? $either->{Name} : "Any $either"; + } + sub named { + my $class = shift; + my $name = shift; + my $self = { Name => $name }; + bless $self, $class; + } + +Of course, we still need to override C<named> in order to handle +constructing a C<Sheep> with a certain color: + + ## in Sheep + sub named { + my ($class, $name) = @_; + my $self = $class->SUPER::named(@_); + $$self{Color} = $class->default_color; + $self + } + +(Note that C<@_> contains the parameters to C<named>.) + +What's this C<default_color>? Well, if C<named> has only the name, +we still need to set a color, so we'll have a class-specific default color. +For a sheep, we might define it as white: + + ## in Sheep + sub default_color { "white" } + +Now: + + my $sheep = Sheep->named("Bad"); + print $sheep->{Color}, "\n"; + +outputs: + + white + +Now, there's nothing particularly specific to C<Sheep> when it comes +to color, so let's remove C<Sheep::named> and implement C<Animal::named> +to handle color instead: + + ## in Animal + sub named { + my ($class, $name) = @_; + my $self = { Name => $name, Color => $class->default_color }; + bless $self, $class; + } + +And then to keep from having to define C<default_color> for each additional +class, we'll define a method that serves as the "default default" directly +in C<Animal>: + + ## in Animal + sub default_color { "brown" } + +Of course, because C<name> and C<named> were the only methods that +referenced the "structure" of the object, the rest of the methods can +remain the same, so C<speak> still works as before. + +=head2 A horse of a different color + +But having all our horses be brown would be boring. So let's add a +method or two to get and set the color. + + ## in Animal + sub color { + $_[0]->{Color} + } + sub set_color { + $_[0]->{Color} = $_[1]; + } + +Note the alternate way of accessing the arguments: C<$_[0]> is used +in-place, rather than with a C<shift>. (This saves us a bit of time +for something that may be invoked frequently.) And now we can fix +that color for Mr. Ed: + + my $horse = Horse->named("Mr. Ed"); + $horse->set_color("black-and-white"); + print $horse->name, " is colored ", $horse->color, "\n"; + +which results in: + + Mr. Ed is colored black-and-white + +=head2 Summary + +So, now we have class methods, constructors, instance methods, instance +data, and even accessors. But that's still just the beginning of what +Perl has to offer. We haven't even begun to talk about accessors that +double as getters and setters, destructors, indirect object notation, +overloading, "isa" and "can" tests, the C<UNIVERSAL> class, and so on. +That's for the rest of the Perl documentation to cover. Hopefully, this +gets you started, though. + +=head1 SEE ALSO + +For more information, see L<perlobj> (for all the gritty details about +Perl objects, now that you've seen the basics), L<perltoot> (the +tutorial for those who already know objects), L<perltooc> (dealing +with class data), L<perlbot> (for some more tricks), and books such as +Damian Conway's excellent I<Object Oriented Perl>. + +Some modules which might prove interesting are Class::Accessor, +Class::Class, Class::Contract, Class::Data::Inheritable, +Class::MethodMaker and Tie::SecureHash + +=head1 COPYRIGHT + +Copyright (c) 1999, 2000 by Randal L. Schwartz and Stonehenge +Consulting Services, Inc. + +Copyright (c) 2009 by Michael F. Witten. + +Permission is hereby granted to distribute this document intact with +the Perl distribution, and in accordance with the licenses of the Perl +distribution; derived documents must include this copyright notice +intact. + +Portions of this text have been derived from Perl Training materials +originally appearing in the I<Packages, References, Objects, and +Modules> course taught by instructors for Stonehenge Consulting +Services, Inc. and used with permission. + +Portions of this text have been derived from materials originally +appearing in I<Linux Magazine> and used with permission. |