Object-Oriented Perl (edited – lorraine)

Beginning Perl, Second Edition

Written by James Lee

Note – fix table & empty spaces

Published by Apress

Chapter 12



There are two main schools of thought when approaching a solution to a problem in the programming world. The first school of thought is one that we have used in this book up to this point: procedural programming. This approach is based on what actions to take—procedures—and developing subroutines that carry out those actions. In procedural programming, we take the overall system and break it up into smaller and smaller pieces, code the steps for the individual pieces into functions, and then put the functions together to form the entire system.

The other school of thought is an approach that has been quite popular for the last 10 or 15 years: object-oriented programming (OOP, or simply OO for short). In the OO approach, we take a step back from what the program needs to do and instead look at the nature of the things with which we are working.

In this chapter, we’ll learn how to start thinking in OO terms. OO involves a lot of jargon, so the first thing we’ll do is look in some detail at all the new terms associated with OO and what they mean to a Perl programmer. After that, we’ll see how we go about approaching a problem using this style of programming. We’ll use a Perl module that involves creating an object, and we’ll also construct some object-oriented modules of our own.

This chapter is meant only as a beginning in OO in Perl. For more details, we recommend the excellent book Object Oriented Perl by Damian Conway (Manning Publications, 1999).

Improving Your Vocabulary

Object-oriented programming wouldn’t be a good buzz phrase if it didn’t use a lot of familiar words in unfamiliar contexts. Before we go any further, let’s investigate the jargon that we’ll need in order to understand object-oriented Perl programming.

The first thing to note is that object-oriented programming is a concept, rather than a standard—there are a few things that object-oriented languages should do, a lot they can do, but nothing that they absolutely have to do. Other languages may implement more or less of these ideas than Perl does, and may well do so in a completely different way. We’ll explain here the terms that are most commonly used by object-oriented programmers.

Objects

What is an object, anyway? Previously, we mentioned briefly that an object is a chunk of data that has behaviors, but that’s not all. To be honest, an object can be anything—it really depends on what your application is. For instance, if you’re writing a contact management database, a single contact might be an object. If you’re communicating with a remote computer via FTP, you could make each connection to the remote server an object.

An object can always be described in terms of two things:

  1. What it can do (actions or methods)
  2. What we know about it (information or attributes)

With a “contact record” object, we’d probably know the contact’s name, date of birth, address, and so on—these are the object’s attributes. We might also be able to ask it to do certain things: print an address label for this contact; work out how old they are; or send them an email—these are the object’s methods.

In Perl, what we see as an object is simply a reference—in fact, you can convert any ordi nary reference into an object simply by using the bless() function. We’ll see later on how that happens. Typically, however, objects are represented as references to a hash, and that’s the model we’ll use in this chapter.

Attributes

An attribute is something we know about an object. A contact database object will possess attributes such as date of birth, address, and name. An FTP session will possess attributes such as the name of the remote server we’re connected to, the current directory, and so on. Two contacts will have different values for their name attribute, unless we have duplicates in the database, but they will both have the name attribute.

If we’re using a reference to a hash, it’s natural to have the attributes as hash entries. Our person object then becomes a bless ed version of the following:

my $person = {
   lastname    => "Galilei",
  
firstname   => "Galileo",
   address     => "9.81 Pisa Apts.",
   occupation  => "bombadier"
};

We can get to (and change) our attributes simply by accessing these hash values directly (that is, by saying something like $person->{address} —remember that we use this syntax because we’re dealing with a reference), but this is generally regarded as a bad idea. For starters, it requires us to know the internal structure of the object and where and how the attributes are stored, which, as end users, we should have no need or desire to fiddle with. Secondly, it doesn’t give the object a chance to examine the data you’re giving it to make sure it makes sense. Instead, access to an attribute usually goes through a method.

Methods

A method is anything you can tell the object to do. It could be something complicated, such as printing out address labels and reports, or something simple such as accessing an attribute. Those methods directly related to attributes are called get-set methods, as they’ll typically either get the current value of the attribute or set a new one.

The fact that methods are all about instructions for doing things may give you a clue as to how we represent them in Perl—methods in Perl are just subroutines. However, there is a special syntax called the arrow operator ( -> ), which we use to call methods. So instead of getting the address attribute directly, as in the preceding example, we’re more likely to say something like this:

print "Address: ", $person->address(), "n";

We’re also able to set an attribute (change its value) like this:

$person->address("Campus Mirabilis, Pisa, Italy");

Alternatively, we can call a method to produce an envelope for this object:

$person->print_envelope();

This syntax $object->method(@arguments ) “invokes” the method, which just means that it calls the given subroutine—in our examples this is either address() or print_envelope() . We’ll see how it’s done shortly.

Classes

Our contact object and FTP session object are very different things—they have different methods and attributes. While $person->date_of_birth() may make sense, you wouldn’t expect $ftp_session->date_of_birth() to do anything sensible.

A class is the formal term for a type of object—it is a general description of a group of things. Classes define the methods an object can have and how those methods work. All objects in the Person class will have the same set of methods and possess the same attributes, and these will be different from the FTP class. An object is sometimes referred to as an instance of a class; this just means that it’s a specific thing created from a general category.

In Perl’s object-oriented philosophy, a class is an ordinary package. Let’s start piecing this together:

  1. A method is a subroutine in a package. For instance, the date_of_birth() method in the Person class is merely the subroutine date_of_birth() in the Person package.
  2. Blessing a scalar just means telling it from what package to take its methods. At that point, it’s more than just a complex data structure, or scalar reference. It has attributes—the data we’ve stored in the hash reference or elsewhere; and it has methods—the subroutines in its package; therefore it can be considered a full-fledged object.

Classes can also have what are known as class methods (some programming languages call these static methods). These are methods that do things relevant to the whole class rather than individual objects. Instead of acting on an object, as you would by saying $object->method() , you act on the class: Person->method() . An important thing to note is that Perl doesn’t necessarily know whether a given subroutine is a class method, an object method, or just an ordinary subroutine, so programmers have to do the checking themselves.

Similarly, classes can have attributes that refer to the whole class—in Perl these are just package variables (some programming languages call these static data). For instance, we might have a population attribute in our Person class, which tells us how many Person objects are currently in existence.

One final note—you’ll probably have noticed that we capitalized Person . The Perl convention is to capitalize all class names, so as to help distinguish them from object names.

Polymorphism

The word polymorphism comes from the Greek πολυ µορφου, meaning “many forms.” What it means in object-oriented programming is that a single method can do different things depending on the class of the object that calls it. For instance, $person->address() would return the person’s address, but $ftp_session->address() might return the IP address of the remote server. On the other hand, $object->address() would have to do the right thing according to which class $object was in.

When we invoke $person->address() , we are calling the subroutine Person::address() , and when we invoke $ftp_session->address() , we are calling the subroutine FTP::address() . They’re defined completely separately, in different packages, probably even in different files. Since Perl already knows what class each object belongs to, neither you nor Perl need to do anything special to make the distinction. Perl looks at the object, finds the class it is in, and calls the subroutine in the appropriate package. This brings us to . . .

Encapsulation

One of the nice things about object-oriented programming is that it hides complexity from the user—this is known as encapsulation (or abstraction). This means that users of the object need not care how the class is structured or how the attributes are represented in the object. Nor do users have to care how the methods work or where they come from—they can just use them.

This also means that the author of the class has complete freedom to change its internal workings at any time. As long as the methods have the same names and take the same arguments, all programs using the class should continue to work and produce the same results. That is as long as they use the method interface, or way of invoking the method, as they should, rather than trying to access or modify the data directly.

In this sense, working with objects is a little like driving a car. Our object, the car, has a set of attributes, such as the model, current speed, and amount of fuel in the tank. We can’t get at these directly, but some read-only methods like the speedometer and the fuel gauge expose them to us. It also provides us with some more methods and a well-defined interface to get it to do things.

We have a pedal to make it accelerate and one to make it brake, a stick to change gear, a hole to put fuel into the tank, and so on. We don’t actually need to know how the engine works if we’re prepared to stick to using these methods; of course, we do need to know what each of them does. We don’t even need to know the whereabouts of the fuel tank, we just put fuel in the appropriate place. If we really want to, we can lift the hood, look inside it, and fiddle with it—but then we only have ourselves to blame if it breaks!

Inheritance

Another property that makes object-oriented programming easy to use is its support for inheritance. Classes can be built quickly by specifying how they differ from other classes. For example, humans inherit attributes from their parents, such as hair color and height, while Perl’s classes inherit methods. If a class inherits from another class, it receives the ability to call every method defined by the class from which it inherits. If the new class wants to implement a method differently, it defines the method in its own class. If it doesn’t want its own version of the method, it will automatically get the method from the parent class. The parent class, which provides the new class with the methods, is called the superclass or base class, and the class which inherits from the superclass is known as a subclass or derived class.

The relationship between the classes can be described as an IS-A relationship. If we have a superclass Animal , we may create a subclass Vertebrate . We could then say that a Vertebrate IS-A Animal . In fact, the classification system for animals can be thought of as a series of IS-A relationships, with more specific subclasses inheriting properties of their superclasses:

Here we see that vertebrates and invertebrates are both subclasses of a general animal class. They both inherit the fact that they are alive, and so we need not specify this in the subclass. Next we could create an Animal::Vertebrate::Mammal class, which would be a subclass of Animal::Vertebrate . We wouldn’t need to specify that the mammal had a backbone or was alive, because these characteristics would be inherited from the superclass.

We won’t talk much about inheritance in this book. This topic is perhaps the most difficult topic in OO and deserves a chapter, if not several chapters, of its own. Once you grasp the basic concepts of OO, we recommend that you check out the book Object Oriented Perl for an excellent discussion of inheritance.

Constructors

Objects have to come from somewhere, and in keeping with the principles of encapsulation, users of a class shouldn’t be expected to put together an object themselves. This would require knowledge of how the object is represented and what initialization is required. To take this responsibility away from the user, there’s a class method that all classes should possess—it’s called the constructor.

As the name implies, this constructs and returns a new object. For this reason, it’s usually called new() .1 We may pass arguments to the constructor, which it can then use to do the initial setup of the object. Sometimes these arguments are in the form of a hash, allowing us to create an object like this:

my $galileo = Person->new(
   lastname    => "Galilei",
  
firstname   => "Galileo",
   address     => "9.81 Pisa Apts.",
   occupation  => "bombadier",
);

There’s also another syntax for calling methods, which you’ll particularly see used with the constructor:

my $galileo = new Person (…);

The constructor will now check that the arguments are acceptable, do any conversion it requires, and create a hash reference, bless() it, and return it to us. More on this later in this chapter.

Destructors

When the object is no longer in use—when it’s a lexical variable that goes out of scope—Perl automatically destroys it. However, before doing so, Perl will attempt to call a method named DESTROY() . If the class provides this method, it should be responsible for any tasks that need to be performed before the object is disposed of. For instance, our FTP session object will want to ensure that it has closed the connection to the remote server.

An Example

It is now time for an example. Let’s start off by using a class that is already created for us: Net::FTP.2 This class (also known as a module) allows us to create objects that transfer files to and from an FTP server. The following example will connect to a famous website in the Perl world—the CPAN3 (more on CPAN in Chapter 13)—and download the README.html file. This example will illustrate some of the buzz words mentioned previously.  

We’ll now use the Net::FTP module to create an object that will let us get files from an FTP site. In our case, we’ll connect to CPAN and download the README.html file.

#!/usr/bin/perl -w
# ftp.pl

use strict;
use Net::FTP;

my $ftp = Net::FTP->new(ftp.cpan.org)
   or die "Couldn’t connect:
$@n";

$ftp->login("anonymous");
$ftp->cwd("/pub/CPAN");
$ftp->get("README.html");
$ftp->close();

Network and firewalls permitting, this should retrieve the file—although it may take some time. Here is the proof on a Windows machine:

$ perl ftp.pl
$ dir README.html
README~1 HTM       2,902 … … README.html
$

The first line of interest in this program is

use Net::FTP;

This line finds the file that contains the definition of the Net::FTP class (its name happens to be FTP.pm and it is located in a directory named Net ) and compiles it for use with our program. More on this in the next section.

After loading the Net::FTP module, we create ourselves an object:

my $ftp = Net::FTP->new(ftp.cpan.org)
   or die "Couldn’t connect: $@n";

Our class is called Net::FTP , the same as the module—this is because, as mentioned previously, a class is just an ordinary package.

We create the object by calling the constructor, which is the class method new() . This takes a number of arguments: a remote machine to which we want to connect and a hash specifying things like whether we have a firewall, which port to connect to, whether we want debugging information, and so on. These arguments will become the attributes of the object. If we don’t specify them, the constructor comes up with some sensible defaults for us. In our case, the defaults are fine, so we just need to supply a remote machine—we’ll use the CPAN server, ftp.cpan.org .

When we call the constructor, it takes our argument (the remote host), and stashes it away internally in the object—encapsulation means we don’t need to know how or where. Then it takes a reference to that hash, bless es the reference, and returns it to us. That
bless ed reference is our new object (our FTP session), and we’re now ready to do things with it (more on bless() later in this chapter).

Then we see a call to the login() method:

$ftp->login("anonymous");

First of all, we have to log in to the server. The usual way of getting things from an FTP server is by logging in with a username of “anonymous” and your email address as the password. The login() method tells the object to issue the appropriate login commands.

How did Perl know that it should use Net::FTP::login() rather than any other login() ? When our constructor bless ed the reference, it gave the reference knowledge of where to find the methods. To quote from the perlobj documentation, “an object is just a reference that happens to know which class it belongs to.”

Since Perl takes care of passing the object to the subroutine as the first parameter, the method automatically receives all the data it needs. This means we can easily have multiple objects doing different things.

my $ftp1 = Net::FTP->new(ftp.cpan.org);
my $ftp2 = Net::FTP->new("ftp.apress.com"); $ftp1->login("anonymous");

The object $ftp1 is just a bless ed reference to a hash, and that hash contains all the data about the connection to CPAN, like the settings, the filehandles, and anything else that Net::FTP needs to store. These are the object’s attributes. Everything we know about the connection is bundled into that object. The important thing to note is that it’s completely independent from $ftp2 , which is another object containing another set of data about a different connection. Hence, the method call $ftp1->login() has no impact on the other connection at all.

After logging in, we change the working directory on the target machine and get the file.

$ftp->cwd("/pub/CPAN");
$ftp->get("README.html");

cwd() and get() are two more methods our object supplies. The object has a huge number of methods, due to the fact that it has a long chain of inheritance. However, there are some methods Net::FTP defines directly that you should know about. They mainly relate directly to FTP commands—Table 12-1 presents an incomplete list of them.

Table 12-1.  Net::FTP Methods  

Method Name

Behavior

$ftp->login($login,$passwd)

Log into the server with the given username and

 

password.

$ ftp->type($type)

Set the transfer type to ASCII or binary; this is quite

$ ftp->ascii()

similar to Perl’s binmode operator.

$ ftp->binary()

 

$ ftp->rename($old,$new)

Rename a file.

$ ftp->delete($file)

Delete a file.

$ ftp->cwd($directory)

Change directory on the FTP server.

$ ftp->pwd()

Give the name of the current directory.

$ ftp->ls()

List the current directory on the FTP server.

$ ftp->get($remote, $local, $offset)

Get a file from the remote server.

$ ftp->put($local, $remote)

Put a file to the remote server.

There are also some get-set methods that will affect the object’s attributes—for instance, the $ftp->hash() method controls an attribute that determines whether or not to print a # character after every 1024 bytes transferred.

After we’ve called the get() method to get our file, we’ll call the close() method to shut down the connection to the server.

$ftp->close();

So, we’ve used our first class. Hopefully, you can see that using objects and classes in Perl is just as easy as calling functions. In fact, it’s easier—Perl not only takes care of finding out where to find the subroutine you’re trying to call, but it also takes care of passing a whole bunch of data to the subroutine for you.

Because this all goes on behind the scenes, we can happily pretend that an object contains a bunch of methods that act on it, and it alone. In fact, it doesn’t—it only contains information regarding where to find methods that can act on any object in that class.

Including Other Files with use

In ftp.pl we saw this statement:

use Net::FTP;

As mentioned previously, this statement attempts to locate a file named FTP.pm in a directory named Net . The .pm filename extension means that this is a “Perl module,” or a collection of data and functions in its own package (more on this later in this chapter).

What we want to do is get Perl to read the .pm file and use it as part of our own program. We have three ways of doing this: do , require , and use .

do

This is the most difficult of the three to understand—the others are just slightly varied forms of do .

do will look for a file by searching the @INC path (more on that later). If the file can’t be found, it will silently move on. If it is found, it will run the file just as if it was placed in a block within our main program—but with one slight difference: we won’t be able to see lexical variables from the main program once we’re inside the additional code. So if we have a file dothis.pl :

#!/usr/bin/perl – w
# dothis.pl

use strict;

my $a = "Been there, done that, got the T-shirt";
do "printit.pl";

and a file printit.pl :

print $a ;
print "this should go to standard output…n";

dothis.pl will do , or execute, the file printit.pl . This means that the contents of printit.pl are compiled and executed. Executing this code produces the following:

$ perl dothis.pl
Use of uninitialized value in print at printit.pl line 1.
this should go to standard output…
$

The first line of output is a warning that $a is undefined. The second line of output is a result of executing the second print() function.

This program shows that do can execute arbitrary code in another file. On the other hand, we can have subroutines in our included file and call them from the main file.

require

require is like do , but it’ll only do it once. It’ll record the fact that a file has been loaded, and will henceforth ignore further requests to require it again. It also fails with an error if it can’t find the file you’re loading.  

#!/usr/bin/perl -w
# cantload.pl

use strict;

require "not_there.pl";

will die() with an error like this:

$ perl cantload.pl
Can’t locate not_there.pl in @INC (@INC contains:
/usr/local/lib/perl5/5.8.3/cygwin /usr/local/ lib/perl5/5.8.3
/usr/local/lib/perl5/site_perl/5.8.3/cygwin
/usr/local/lib/perl5/site_perl/5.8.3 /usr/local/ lib/perl5/site_perl .)
at cantload.pl line 6.
$

This is the @INC array, which contains a list of paths in which Perl looks for modules and other additional files. The first two paths are where Perl keeps the standard library. The first includes the word cygwin , which is the operating system this example is running on and that contains the parts of the library specific to this operating system. The second is the part of the standard library, which does not depend on the operating system. In Windows, these two libraries are C:/Perl/lib and C:/Perl/site/lib by default.

The next two paths are the local “site” modules, which are third-party modules that we’ll install from CPAN or create ourselves. They’ve got the version (5.8.3) in there to remind us that these are modules specific to that version—the next path doesn’t have a Perl version number in it, and that’s for site modules which do not need a particular version of Perl. Finally, the . represents the current directory.

You can also use require like this:

require Wibble;

Using a bareword tells Perl to look for a file called Wibble.pm in the @INC path. It also converts any instance of :: into a directory separator. For instance:

require Monty::Python;

will send Perl looking for Python.pm in a directory called Monty , which is itself in one of the directories given in @INC .

use

The way we normally use modules is, logically enough, with the use statement. This is like require, except that Perl applies it before anything else in the program starts—if Perl sees a use statement anywhere in your program, it’ll include that module. So, for instance, you can’t say this:  

if ($graphical) {
   use MyProgram::Graphical;
} else {
  
use MyProgram::Text;
}

because when Perl’s reading your program, it will include both modules—the use takes place way before the value of $graphical is decided. We say that use takes place at compile time and not at run time.

Changing @INC

The default contents of the search path @INC are decided when Perl is compiled—if we move those directories elsewhere, we’ll have to recompile Perl to get it working again. However, we can tell it to search in directories other than these—@INC is an ordinary array, so you might expect us to be able to say

unshift @INC, "my/module/directory";
use Wibble;

However, this isn’t going to work. Why not? Remember that the preceding statement will execute at run time. Unfortunately the use statement takes place at compile time, well before that. No problem! There’s a special subroutine called BEGIN that is guaranteed execution at compile time, so we can put it there:

sub BEGIN {
   unshift @INC, "my/module/directory";
}
use Wibble;

Now that’ll work just fine—however, it’s a little messy, and what’s more, there’s an easier way to do it. We can use the lib pragma to add our directory to @INC before anything else gets a chance to look at it:

use lib "my/module/directory";
use Wibble;

The directory that is indicated is inserted into the front of @INC so that it is the first direc tory searched when Perl is looking for the module.

Rolling Your Own Classes

We’ve seen how to use a class and an object. Let’s now see how to make our own classes. As an example, we’ll implement the Person class we used in our definitions.

As we mentioned previously, a class is just a package—nothing more, nothing less. So the simplest class looks like this:

package Person;

That’s it. However, this class has nothing—no methods, no attributes, no constructor, nothing. It’s a totally empty class. We will eventually want to add more stuff (attributes and methods) to this class.4

Usually, you’ll want to put your class into its own file. It’s not necessary by any means, but it gets the implementation out of the way. So, let’s create a module by putting the following in the file Person1.pm . The file must end in the .pm file extension because when we use this class we will say

use Person1;

and this looks for the file named Person1.pm . Here is its content:

package Person1;
# Person1.pm

# Class for storing data about a person

use strict;

1;

Normally, the name of the package is the same as the name of file (minus the .pm extension). So if the package name is Person1 , the filename is Person1.pm . Likewise, if the filename is Person1.pm , the package name is Person1 .

As we discuss the various features of OO in this chapter, we will develop a class that represents a person. We will start with package Person1 , then enhance that package to be Person2 , and so on. Keep in mind that these packages are representing an evolution of a definition.

That 1; at the end of the file looks weird, but it is necessary because Perl expects to see a true value as the last thing in the package; this tells Perl that everything went OK when loading the file. Now in a separate program, we can say use Person1; and start using the class, like this:

#!/usr/bin/perl -w
# person1.pl

use strict;
use Person1;

This program doesn’t do anything except read in and compile the class we created, because we can’t yet create any objects as we do not yet have a constructor. Therefore, the next step is to write a constructor.

What does our constructor create? It creates an object, which is a bless ed reference. Before we go any further, then, let’s have a look at what bless() is and what it does.

Bless You, My Reference

The bless() function takes a reference and turns it into an object. The way it does that is simple: it changes the type of the reference. Instead of being an array reference or a hash reference, Perl now thinks of it as a Person1 reference (or whatever other class we bless() the reference into).

We can use the ref() function to tell us what type of reference we have:

#!/usr/bin/perl – w
# reftypes.pl

use strict;

my $a = [];
my $b = {};
my $c = 1;
my $d = $c;
print ‘$a is a ‘, ref($a), " referencen"; print ‘$b is a ‘, ref($b), " referencen"; print ‘$c is a ‘, ref($c), " referencen"; print ‘$d is a ‘, ref($d), " referencen";

$ perl reftypes.pl
$a is a ARRAY reference
$b is a HASH reference
$c is a SCALAR reference
$d is a REF reference
$

The syntax of bless() is

bless(reference, package);

If the package isn’t given, the reference is bless ed into the current package. Let’s bless() a reference into the Person1 package.

#!/usr/bin/perl -w
# bless1.pl

use strict;

my $a = {};

print ‘$a is a ‘, ref($a), " referencen";

bless($a, "Person1");

print ‘$a is a ‘, ref($a), " referencen";

$ perl bless1.pl
$a is a HASH reference
$a is a Person1 reference
$

Okay, so we’ve changed $a into a Person1 reference. So what just happened?

Actually, nothing changed in the structure of $a at all. It’s still a hash reference, and we can still dereference it—or add, access, and delete entries in the hash, and so on. It still has the same keys and values. Nothing magical has happened.

But $a is now a reference with knowledge of which package it belongs to, and if we try and call a method with it, Perl now knows that it should look in the Person1 package for a defini tion of that method. It has become an object.

What if we bless() it again? What happens then? Let’s try it.

#!/usr/bin/perl -w
# bless2.pl

use strict;

my $a = {};

print ‘$a is a ‘, ref($a), " referencen";

bless($a, "Person1") ;
print ‘$a is a ‘, ref($a), " referencen";

bless($a, "Animal::Vertebrate::Mammal");
print ‘$a is a ‘, ref($a), " referencen";

$ perl bless2.pl
$a is a HASH reference
$a is a Person1 reference
$a is a Animal::Vertebrate::Mammal reference $

All that’s happened is we’ve once again changed what type of reference it is. We’ve changed where Perl should look if any methods are called by the reference. Note that at this stage we haven’t even defined an Animal::Vertebrate::Mammal package, but that’s OK because we’re not going to call any methods yet—if we did, they would surely fail.

Again, the internal structure of that reference hasn’t changed. It’s still a hash reference with the same keys and values. You usually don’t want to bless() an object that’s already been bless ed. This is because something that was originally a Person1 may have different attributes to what the new class expects it to have when methods are called. Worse still, the program using the object could well try and call a method that was fine in the old class but doesn’t exist in the new one—attempting to magically turn a person into an FTP session can only have undesirable (and pretty weird) results.

Storing Attributes

Before we look at methods, let’s examine attributes. An attribute is, as defined at the start of this chapter, something we know about the object. In other words, it’s a piece of data that belongs to this particular object. How do we store this data, then?

This is what the reference is for; if we store our data in the reference, our object carries around both a set of data unique to it and knowledge of where to find methods to act on that data. If we know that our object is only going to contain one attribute, one piece of data, we could conceivably use a scalar reference, like this:

my $attribute = "green";
my $object = $attribute;
bless $object, "Simple";

Now we have a nice simple object that stores a single attribute contained in the Simple class. We can access and change the attribute just as we’d work with an ordinary scalar refer ence:

$var       = ${$object};
${$object} = "red";

This is nice and simple, but it’s not very flexible. Similarly, we could have an array reference and bless() that to turn it into an object, which is slightly more flexible. We can access attributes as elements in the array, and we can add and delete attributes by using array operations. If we are storing a set of unnamed data, this is perfectly adequate.

However, for maximum flexibility, we can use a hash to give names to our attributes. Here is an example of creating a reference to an anonymous hash and then bless ing it as an object of our class:

my $object = {
  
lastname    => "Galilei",
  
firstname   => "Galileo",
  
address     => "9.81 Pisa Apts.",
   occupation  => "bombadier",
};
bless $object, "Person1";

This allows us easy access to the individual attributes, as if we were carrying a bunch of variables around with us. Therefore, we generally use an anonymous hash reference for any nontrivial class.

The Constructor

We’re now ready to create objects. Let’s put this knowledge into a constructor, and put a constructor into our currently empty Person1 class. As mentioned previously, our definition of a person is a work in progress, so we will call the next version Person2 and store it in Person2.pm.

To construct an object, we make a hash reference, and bless() it as an object of the class.

package Person2 ;
# Person2.pm

# Class for storing data about a person

use strict;

sub new {
   my $self = {};
   bless $self, "Person2";
   return $self;
}

1;

Now we can use our Person2 class to create an object:

#!/usr/bin/perl -w
# persontest.pl

use strict;
use Person2;

my $person = Person2->new();

which should execute without any errors.

Our constructor does a simple job, and does it well. First, we create our hash reference:

my $self = {};

$self is the traditional name for an object when it’s being manipulated by methods inside the class. Now we’ll turn it into an object by telling it which class it belongs to:

bless $self, "Person2";

Finally, we return the object:

return $self;

Excellent. Now let’s see how we can improve this.

Considering Inheritance

It’s possible that someone someday will want to inherit from this class, and we won’t neces sarily be told about it. If they don’t provide their own constructor, they’ll get ours, and as things stand, that’ll produce an object bless ed into our class—not theirs.

We really need to remove the hard-wired "Person2" in our constructor and replace it with the called class. How do we know what the called class is though? Perl translates Class->new() into new("Class") . In other words, the class name is magically passed into the constructor as its first argument. Therefore, we know what class the user wants because it’s the first argument to the constructor. All we need to do is take that argument and use that as the class to bless() into (the second argument to the bless() function). So here’s a more general constructor that takes inheritance into account:

sub new {
   my $class = shift;
  
my $self = {};
  
bless $self, $class;
   return $self;
}

As usual, shift() without any arguments means shift @_ —it takes the first element of the argument array. This gives us the first thing we were passed, the class name. We can therefore use this to bless our reference without needing to hard-code the name.

Providing Attributes

Now let’s make one more enhancement. At the moment, we can create a completely anonymous Person2 with no attributes at all. We want to be able to give the end user of the class the opportunity to specify some attributes when the object is created. So let’s take the next step in our evolution and define class Person3 .

As before, we’re going to store the data in a hash reference. The object’s data will be provided to the constructor through its argument list. Ideally, we’ll want the constructor to be called something along these lines:

my $object = Person3->new(
   lastname    => "Galii",
   firstname   => "Galileo",
   address     => "9.81 Pisa Apts.",
   occupation  => "bombardier"
);

This is the easiest syntax for the user, because it allows them to specify the attributes in any order, and give as many or as few as they want. It’s also a lot easier to use and remember than if we make them use a list like this:

my $object = Person3->new ("Galilei","Galileo","9.81 Pisa Apts.","bombardier");

In fact, it’s the easiest syntax for us too. Since we want our attributes stored in a hash, and the key-value syntax we proposed previously is a hash, all we’ve got to do is place the arguments straight into our hash reference:

my $self = {@_};

Let’s plug this into our package:

package Person3 ;
# Person3.pm

# Class for storing data about a person

use strict;

sub new {
   my $class = shift;
   my $self = {@_};
   bless $self, $class;
   return $self;
}
 

1;

What have we done? Since Perl magically passes in the class name as the first argument to the function, Perl sees something like this when we call the constructor:

@_ = (
   "Person3",
   "lastname",   "Galilei",
   "firstname",  "Galileo",
   "address",    "9.81 Pisa Apts.", 
   "occupation", "bombardier"
);

The first line of the constructor grabs the class name as before.

my $class = shift;

Now what’s left in the argument array @_ is

@_= (
   "lastname",   "Galilei",
   "firstname",  "Galileo",
  
"address",    "9.81 Pisa Apts.",
   "occupation", "bombardier"
);

This is what we put verbatim into our hash reference:

my $self = {@_};

Our hash now contains all the attributes we provided. As usual, it’s bless ed and returned to the caller.

We now have a full-featured constructor. We’ve taken some initial data and constructed an object out of it, storing the data as attributes in the object. Now it’s time to add some methods so we can actually do something with it!

Creating Methods

Our constructor was a class method; creating an object method will be very similar. In the same way that a class method magically gets passed the name of the class as the first argument, an object method is just a subroutine that magically gets passed the object as the first argument.

Let’s create a method to return the last name of the person. This directly accesses an attribute—sometimes called an accessor method. Remember that the lastname attribute is just an entry in the hash, referenced by the object. So what does this involve? We’ll need to

  1. Receive the object being passed to us.
  2. Extract the lastname entry from the hash. 
     
  3. Pass it back to the caller.

Using the techniques we learned in Chapter 11 for directly accessing values in a hash reference, we can code the accessor and add it into our class creating the next iteration, Person4 .

package Person4;
# Person4.pm

# Class for storing data about a person

use strict;

sub new {
   my $class = shift;
   my $self = {@_};
  
bless $self, $class;
  
return $self;
}

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

1;

Now we can create an object with some attributes, and retrieve the attributes again.

#!/usr/bin/perl – w
# accessor1.pl

use strict;
use Person4;

my $object = Person4->new(
   lastname   => "Galilei",
  
firstname  => "Galileo",
  
address    => "9.81 Pisa Apts.",
   occupation => "bombadier"
);

print "This person’s last name: ", $object->lastname(), "n";

If all is well, we should be told the last name.

$ perl accessor1.pl
This person’s last name: Galilei
$

Our accessor method is a very simple one—it takes an object, and extracts an attribute from it. First, we use shift() to get the object passed to us.

my $self = shift;

Then we take out the relevant hash entry and pass it back.

return $self->{lastname};

Don’t confuse the arrow used here for accessing parts of a reference with the arrow used as a method call. When accessing a reference, there will be either a curly brace or a square bracket at the end of the arrow.

$reference->{lastname}; # Accesses a hash reference
$reference->[3];        # Accesses an array reference

When calling a method, there will be a name following the arrow.

$reference->lastname();

So while our method is called with $object->lastname() , the last name entry in the hash is accessed with $self->{lastname} .

Get-Set Methods

As well as getting the value of an attribute, we may well want to set or change it. The syntax we’ll use is as follows:

print "Old address: ", $object->address(), "n";
$object->address("Campus Mirabilis, Pisa, Italy");
print "New address: ", $object->address(), "n";

This kind of accessor is called a get-set method because we can use it to both get and set the attribute. Turning our current read-only accessors into accessors that can also set the value is simple. Let’s create a get-set method for address() :

sub address {
   my $self = shift;

   # Receive more data
   my $data = shift;

   # Set the address if there’s any data there.
   $self->{address} = $data if defined $data;

   return $self->{address};
}

If we don’t particularly want to trap calling the method as a class method (since it’ll generate an error when we try to access the hash entry anyway), we can write really miniature get-set methods like this:

sub address   { $_[0]->{address  } = $_[1] if defined $_[1]; $_[0]->{address  } }
sub lastname  { $_[0]->{lastname } = $_[1] if defined $_[1]; $_[0]->{lastname } }
sub firstname { $_[0]->{firstname} = $_[1] if defined $_[1]; $_[0]->{firstname} }

While that’s fine for getting classes up and running quickly, writing out the get-set method in full as shown previously allows us to easily extend it in various ways, like testing the validity of the data, doing any notification we need to when the data changes, and so on.

Class Attributes

Classes can have attributes, too—instead of being entries in a hash, they’re variables in a package. Just like object attributes, it’s a really good idea to access them through get-set methods, but since they’re ordinary variables, our methods are a lot simpler. Let’s use a class attribute to keep score of how many times we’ve created a Person5 object ( Person5 is our next step in creating our definition of a person). We’ll call our attribute $Person5::Population , and we’ll get the current value of it via the method headcount() .

A class attribute is a package variable, and an accessor method just returns or sets the value of that variable. Here, we make our accessor method read-only to stop the end user changing it and confusing their own code:

package Person5;
# Person5.pm

# Class for storing data about a person

use strict;

my $Population = 0;

sub new {
   my $class = shift;
   my $self = {@_};
   bless $self, $class;
   $Population++;
   return $self;
}

# Object accessor methods
sub address   { $_[0]->{address    } = $_[1] if defined $_[1]; $_[0]->{address  } }
sub lastname  { $_[0]->{lastname   } = $_[1] if defined $_[1]; $_[0]->{lastname } }
sub firstname { $_[0]->{firstname} = $_[1] if defined $_[1]; $_[0]->{firstname} }
sub phone_no  { $_[0]->{phone_no } = $_[1] if defined $_[1]; $_[0]->{phone_no } }
sub occupation  {
   $_[0]->{occupation}=$_[1] if defined $_[1]; $_[0]->{occupation}
}

# Class accessor methods
sub headcount { return $Population; }

1;

Now as we create new objects, the population increases:

#!/usr/bin/perl – w
# classatr1.pl

use strict;
use Person5;

print "In the beginning: ", Person5->headcount(), "n";
my $object = Person5->new(
   lastname    => "Galilei",
   firstname   => "Galileo",
   address     => "9.81 Pisa Apts.",
   occupation  => "bombadier"
);
print "Population now: ", Person5->headcount(), "n";

my $object2 = Person5->new(
  
lastname    => "Einstein",
   firstname   => "Albert",
   address     => "9E16, Relativity Drive",
   occupation  => "Plumber"
);
print "Population now: ", Person5->headcount(), "n";

$ perl classatr1.pl
In the beginning: 0
Population now: 1
Population now: 2
$

There’s actually nothing object-oriented-specific about this example. All we’re doing is taking advantage of the way Perl’s scoping works. A lexical variable can be seen and used by anything in the current scope and inside any curly braces. So, naturally enough, with

Package Person5;

my $Population;

sub headcount { return $Population; }

the package variable $Population is declared at the top of the package, and is therefore visible everywhere in the package. Even though we call headcount() from another package, it accesses a variable in its own package.

Similarly, when we increment its value as part of new() , we’re accessing a variable in the same package. Since it’s a package variable, it stays around for as long as the package does, which is why it doesn’t lose its value when we do things in our main program.

Let’s make one more addition and create the Person6 class: we’ll allow our main program to process all of the names of people in our contacts database, and we’ll have a class method to return to us an array of the objects created. Instead of keeping a separate variable for the population, we’ll reimplement $Population in terms of the scalar value of that array.

package Person6;
# Person6.pm

# Class for storing data about a person

use strict;

my @Everyone;

sub new {
   my $class = shift;
   my $self = {@_};
   bless $self, $class ;
   push @Everyone, $self;
  
return $self;
}
 

# Object accessor methods
sub address   { $_[0]->{address  } = $_[1] if defined $_[1]; $_[0]->{address  } }
sub lastname  { $_[0]->{lastname } = $_[1] if defined $_[1]; $_[0]->{lastname } }
sub firstname { $_[0]->{firstname} = $_[1] if defined $_[1]; $_[0]->{firstname} }
sub phone_no  { $_[0]->{phone_no } = $_[1] if defined $_[1]; $_[0]->{phone_no } }
sub occupation  {
  
$_[0]->{occupation}=$_[1] if defined $_[1]; $_[0]->{occupation}
}

# Class accessor methods
sub headcount { return scalar @Everyone; }
sub everyone  { return @Everyone;    }

1;

Note that we’re pushing one reference to the data onto the array, and we return another reference. There are now two references to the same data, rather than two copies of the data. This becomes important when it comes to destruction. Anyway, this time we can construct our objects and loop through them.

#!/usr/bin/perl – w
# classatr2.pl

use strict;
use Person6;

print "In the beginning: ", Person6->headcount(), "n";
my $object = Person6->new(
   lastname    => "Galilei",
   firstname   => "Galileo",
   address     => "9.81 Pisa Apts.",
   occupation  => "bombadier"
);
print "Population now: ", Person6->headcount(), "n";

my $object2 = Person6->new(
   lastname    => "Einstein",
   firstname   => "Albert",
  
address     => "9E16, Relativity Drive",
   occupation  => "Plumber"
);
print "Population now: ", Person6->headcount(), "n";

print "nPeople we know:n";
foreach my $person(Person6->everyone()) {
  
print $person->firstname(), " ", $person->lastname(), "n";
}

$ perl classatr2.pl
In the beginning: 0
Population now: 1
Population now: 2

People we know:
Galileo Galilei
Albert Einstein
$

Normally, you won’t want to do something like this. It’s not the class’s business to know what’s being done with the objects it creates. Since we know that in these examples we’ll be putting all the Person6 objects into a database, it’s reasonable to get the whole database with a single method. However, this isn’t a general solution—people may not use the objects they create, or may use them in multiple databases, or in other ways you haven’t thought of. Let the user keep copies of the object themselves.

Privatizing Your Methods

The things we did with our class attributes in new() in the two preceding examples were a bit naughty. We directly accessed the class variables, instead of going through an accessor method. If another class wants to inherit from this class, it has to make sure it too carries a package variable of the same name in the same way.

What we usually do in these situations is to put all the class-specific parts into a separate method, and use that method internally in the class. Inheriting classes can then replace these private methods with their own implementations. To mark a method as private, for use only inside the class, it’s customary to begin the method’s name with an underscore. Perl doesn’t treat these methods any differently—the underscore means nothing significant to Perl but is purely for human consumption. Think of it as a “keep out” sign to mark the method as for use by authorized personnel only!

Typically, the constructor is one place where we’ll want to do a private setup, so let’s convert the code for adding to the @Everyone array into a private method in the class Person7 :

package Person7;
# Person7.pm

# Class for storing data about a person

use strict;

my @Everyone;

# Constructor and initialization
sub new {
   my $class = shift;
   my $self = {@_};
   bless $self, $class;
   $self->_init();
  
return $self;
}
 

sub _init {
   my $self = shift;
   push @Everyone, $self;
}

# Object accessor methods
sub address   { $_[0]->{address  } = $_[1] if defined $_[1]; $_[0]->{address  } }
sub lastname  { $_[0]->{lastname } = $_[1] if defined $_[1]; $_[0]->{lastname } }
sub firstname { $_[0]->{firstname} = $_[1] if defined $_[1]; $_[0]->{firstname} }
sub phone_no  { $_[0]->{phone_no } = $_[1] if defined $_[1]; $_[0]->{phone_no } }
sub occupation  {
  
$_[0]->{occupation}=$_[1] if defined $_[1]; $_[0]->{occupation}
}

# Class accessor methods
sub headcount { return scalar @Everyone; } sub everyone  { return @Everyone;        }

1;

What we have now is pretty much the standard constructor. Let’s go over it again:

sub new {

First, we retrieve our class name, which will be passed to us automatically when we do Class->new() , by using shift as a shorthand for shift @_ .

  my $class = shift;

Then we put the rest of the arguments, which should be a hash with which to initialize the attributes, into a new hash reference.

  my $self = {@_};

Now we bless() the reference to tell it which class it belongs to, making it an object.

bless $self, $class;

Do any further initialization we need to do by calling the object’s private _init() method. Note that due to inheritance, this private method may be provided by a subclass.

  $self->_init();

Finally, return the constructed object.

   return $self;
}

Utility Methods

Our methods have mainly been accessors so far, but that’s by no means all we can do with objects. Since methods are essentially subroutines, we can do almost anything we want inside them. Let’s now add some methods that do things—utility methods:

package Person8;
# Person8.pm

# Class for storing data about a person

use strict;

my @Everyone;

# Constructor and initialization
#…

# Object accessor methods
#…

# Class accessor methods
#…

# Utility methods
sub fullname {
  
my $self = shift;
   return $self->firstname() . " " . $self->lastname();
}

sub printletter {
   my $self      = shift;
   my $name      = $self->fullname();
   my $address   = $self->address();
   my $firstname = $self->firstname();
   my $body      = shift;
  
my @date      = (localtime)[3,4,5];
   $date[1]++;      # Months start at 0! Add one to humanize!

   $date[2]+=1900;  # Add 1900 to get current year.
  
my $date    = join "/", @date;

   print <<EOF ;
$name
$address

$date

Dear $firstname,

$body

Yours faithfully,
EOF
  
return $self;
}

1;  

This adds two methods, fullname() and printletter() . fullname() returns the full name of the person the object describes. printletter() prints out a letter with a body supplied by the user. Notice that to print the name in the text of the letter, printletter() itself calls fullname() . It’s good practice for utility methods to return the object if they have nothing else to return. This allows you to string together calls by using the returned object as the object for the next method call, like this: $object->one()->two()->three(); .

Here’s an example of those utility methods in use:

#!/usr/bin/perl – w
# utility1.pl

use strict;
use Person8;

my $object = Person8->new(
  
lastname    => "Galilei",
   firstname   => "Galileo",
  
address     => "9.81 Pisa Apts.",
   occupation  => "bombadier"
);
$object->printletter("You owe me money. Please pay it.");

This produces our friendly demand:

$ perl utility1.pl
Galileo Galilei
9.81 Pisa Apts.

4/5/2004

Dear Galileo,

You owe me money. Please pay it.

Yours faithfully,
$

Death of an Object

We’ve seen how we construct an object, and we’ve made ourselves a constructor method that returns a bless ed reference. What happens at the end of the story, when an object needs to be destructed? Object destruction happens in two possible cases, either implicitly or explicitly:

  1. Explicit destruction happens when no reference to the object remains. Just like when dealing with ordinary references, you may have more than one reference to the data in existence. As we saw in Chapter 11, some of these references may be lexical variables, which go out of scope. As they do, the reference count of the data is decreased. Once it falls to zero, the data is removed from the system.
  2. Implicit destruction happens at the end of your program. At that point, all the data in your program is released.

When Perl needs to release data and destroy an object, whether implicitly or explic itly, it calls the method DESTROY() on the object. Unlike other utility methods, this doesn’t mean Perl is telling you what to do. Perl will destroy the data for you, but this is your chance to clean up anything else you have used, close any files you opened, shut down any network sockets, and so on. (Larry Wall joked that it should have been called something like YOU_ARE_ABOUT_TO_BE_SHOT_DO_YOU_HAVE_ANY_LAST_REQUESTS() instead.)

If Perl doesn’t find a method called DESTROY() , it won’t complain but will silently release the object’s data.

Our Finished Class

Let’s put all the pieces of our class together and examine the class all the way through:

package Person8;

First of all, let’s reiterate that a class is nothing more than a package. We start off our class by starting a new package. As usual, we want to make sure this package is at least as pedantic as the one that called it, so we turn on strictness:

# Class for storing data about a person

use strict;

Next we declare our class attributes. These are ordinary package variables.

# Class attribute s
my @Everyone;

We provide a nice and general constructor, which calls a private method to do its private initialization. We take the class name, create a reference, and bless() it:

# Constructor and initialization
sub new {
   my $class = shift;
   my $self = {@_};
   bless $self, $class;
   $self->_init();
   return $self;
}

Our private method just adds a copy of the current object to a general pool. In more elab orate classes, we’d want to check that the user’s input makes sense and get it into the format we want, open any external files we need, and so on.

sub _init {
   my $self = shift;
   push @Everyone, $self;
}

Next we provide very simple object accessor methods to allow us to get at the keys of the hash reference where our data is stored. These are the only interfaces we provide to the data inside the object, and everything goes through them:

# Object accessor methods
sub address   { $_[0]->{address  } = $_[1] if defined $_[1]; $_[0]->{address  } }
sub lastname  { $_[0]->{lastname } = $_[1] if defined $_[1]; $_[0]->{lastname } }
sub firstname { $_[0]->{firstname} = $_[1] if defined $_[1]; $_[0]->{firstname} }
sub phone_no  { $_[0]->{phone_no } = $_[1] if defined $_[1]; $_[0]->{phone_no } }
sub occupation {
  
$_[0]->{occupation}=$_[1] if defined $_[1]; $_[0]->{occupation}
}

Accessing class attributes is even easier, since these are simple variables.

# Class accessor methods
sub headcount { return scalar @Everyone; } sub everyone  { return @Everyone;        }

Finally, we have a couple of utility methods, which perform actions on the data in the object. The fullname() method uses accessors to get at the first name and last name stored in the object, and returns a string with them separated by a space.

# Utility methods
sub fullname {
  
my $self = shift;
  
return $self->firstname() . " " . $self->lastname();
}

Second, printletter() is a slightly more elaborate method that prints out a letter to the referenced person. It uses the address and first name accessors plus the fullname() method to get the object’s details. Notice that in both methods we’re using my $self = shift to grab the object as it was passed to us.

sub printletter {
   my $self      = shift;
   my $name      = $self->fullname();
   my $address   = $self->address();
  
my $firstname = $self->firstname();
   my $body      = shift;
   my @date      = (localtime)[3,4,5];
   $date[1]++;      # Months start at 0! Add one to humanize!
   $date[2]+=1900;  # Add 1900 to get current year.
   my $date    = join "/", @date;

   print <<EOF;
$name
$address

$date

Dear $firstname,

$body

Yours faithfully,
EOF
}

1;

Do You Need OO?

Now that we have discussed the basics of OO in Perl, how do you decide whether or not you should be using a procedural or an OO style in your programs? Here are five guidelines to help you decide.

Are Your Subroutines Tasks?

If your program naturally involves a series of unconnected tasks, you probably want to be using a procedural style. If your application is data-driven, then you’re dealing primarily with data structures rather than tasks, so consider using an OO style instead.

Do You Need Persistence?

After your task is completed, do you need somewhere to store data that you want to receive next time you process that data? If so, you may find it easier to use an OO interface. If each call to a subroutine is completely independent of the others, you can use a procedural interface.

For instance, if you’re producing a cross-reference table, your cross-reference subroutine will need to know whether or not the thing it’s processing has turned up before or not. Since an object packages up everything we know about a piece of data, it’s easy to deal with that directly.

Do You Need Sessions?

Do you want to process several different chunks of data with the same subroutines? For instance, if you have two different “sessions” that signify database connections or network connections, you may find it easier to package up each session into an object.

Do You Need Speed?

Object-oriented programs generally run slower than equally well-written procedural programs that do the same job, because packaging things into objects and passing objects around is expensive both in terms of time spent and resources used. If you can get away with not using object orientation, you probably should.

Do You Want the User to Be Unaware of the Object?

If you want to hide the details of how a thing behaves, OO is a good approach. You can design the object to store the data in any way that you choose, then provide the user with an easy-to-use interface. The user can then use the object without having to know how the information about the object is implemented.

Are You Still Unsure?

Unless you know you need an OO model, it’s probably better to use a procedural model to help maintenance and readability. If you’re still unsure, go with an ordinary procedural model.

Summary

Object-oriented programming is another way of thinking about programming. You approach it in terms of data and the relationships between pieces of data, which we call objects. These objects belong to divisions called classes—these have properties (attributes) and can perform actions (methods).

Perl makes object-oriented programming neat and simple:

  1. An object is a reference that has been blessed into a class.
  2. A class is an ordinary Perl package. 
     
  3. A method is an ordinary Perl subroutine that has the class name or object referenc e magically passed in.

From these three basic principles, we can start to build data-driven applications.

Exercises

  1. Using Person8.pm, write a program to do the following:
    • Create three different Person8 objects.
    • Print the number of Person8 objects. 
       
    • Loop through the Person8 objects and print a letter to each one. 

 


1. It is also called new() so that our C++ brethren will feel a sense of familiarity when they create objects
in Perl.

2. Written by Graham Barr. Thanks, Graham!

3. The Comprehensive Perl Archive Network–CPAN. Don’t confuse this with CSPAN–that is something completely different.

4. Because, let’s face it, there are already enough empty Persons in the world.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye