"""I seem to remember on the training course that you told us how perl is not object oriented. I can see obvious differences between perl and C++, such as the inability to setup private or protected member functions & data, or simply that I am using subroutines instead of classes etc. Perhaps I am being overly pedantic here, but was wondering what exactly is the difference between PERL and an object oriented language such as C++... or maybe more appropriately - what makes PERL 5.x NOT an object oriented language?? Is object orientation not more of a concept rather than a syntax?"""
Let me start with an answer to the last part of the question first.
"IS OBJECT ORIENTATION NOT MORE OF A CONCEPT RATHER THAN A SYNTAX?"
Yes, it's more of a concept.
- The most important aspect of OO is the concept.
- Languages provide facilities to assist with (or enforce)
the use of the concept.
- The syntax of the language is just the outer key through
which you instruct the language.
In other words, it doesn't really matter one iota what the actual syntax of the language is - whether it uses operators like "->" or "." to run a method, whether it uses syntax like '@ISA = ("clothing");' or 'extends clothing' or '(clothing)' to extend a class, etc. It's what the language can do internally - the fact that it provides facilities that at least assist - that really matters.
I SEEM TO REMEMBER ON THE TRAINING COURSE THAT YOU TOLD US
HOW PERL IS NOT OBJECT ORIENTED.
Languages store data in variables in two different ways. Traditional languages have a named variable and it the location that the variable points to you'll find the value that the variable holds. Perl 5 is a "traditional" language in that sense. Languages that are described as "fully object oriented" hold their information in variables that are pointed to (or referenced by) the name - a slightly more complex setup. What does this mean?
It means that if you copy a variable in a language that's not fully Object Oriented, you're probably going to be duplicating the data ... so that changing the copy won't change the original. But if you copy a variable in a language where all the data structures are objects, then you're adding another name to the same piece of data, meaning that a change to the data through one name will be reflected in a change as seen through the other name. Let's see an example in Perl (where a list is NOT an object) and Python (where a list IS an object):
@graham = ("Perl","PHP","Python");
@current = @graham;
$current[1] = "Tcl/tk";
print "@current\n";
print "@graham\n";
We run that in Perl and we have changed @current but NOT @graham:
earth-wind-and-fire:~/mar05 grahamellis$ perl pe1
Perl Tcl/tk Python
Perl PHP Python
earth-wind-and-fire:~/mar05 grahamellis$
The code in Python reads like this:
graham = ["Perl","PHP","Python"]
current = graham
current[1] = "Tcl/tk"
print current
print graham
And when run you'll find that the data has changed under both names
earth-wind-and-fire:~/mar05 grahamellis$ python py1
['Perl', 'Tcl/tk', 'Python']
['Perl', 'Tcl/tk', 'Python']
earth-wind-and-fire:~/mar05 grahamellis$
With Perl, you CAN write code and objects that behave the way that python does intrinsically, and that's object oriented programming in Perl. It works very well, but it doesn't mean that every structure in that resulting Perl program is going to be an object.
WHAT'S THIS ABOUT PUBLIC AND PRIVATE AND PROTECTED?
With an object oriented approach to programming, code and information is separated into objects, each of which belongs to a particular class. In order to keep code maintenance easier, the number of ways that you can access one class from another is limited. Some Object Oriented language such as Java give you the ability as you're defining a class to mark things as being private so that they cannot be accessed from outside - i.e. they enforce the standard. Other such as Python work much more on the basis of trust - things aren't declared as private, but there's actually nothing there to stop you breaking the "rules" if you want to.
Both of these approaches have their merits; the trusting approach (which Perl's objects use) for a project that's being written and maintained by a small team of trusted professionals, and the enforced approach which would be mandatory in something like a major pan-banking system.
PERL / OBJECT ORIENTATION??
In Perl 5, you can define, use and write objects. I recommend you do so to help you reuse code, but it's not essential that you do and for smaller one-off data utility and conversion roles in may not gain you anything. The facilities added to Perl 5 to assist with OO are a little perverse in structure (so you'll benefit from a training course to learn about them), but they work extremely well, and offer some OO facilities that are actually beyond what's offered by Java. (C++ has a similar preversity, forced on it by a need to be compatible with C).
Perl 6 is truely Object orieinted. Like Python, all data structures are objects.
See also
Object Orientation in Perl - course
Please note that articles in this section of our
web site were current and correct to the best of our ability when published,
but by the nature of our business may go out of date quite quickly. The
quoting of a price, contract term or any other information in this area of
our website is NOT an offer to supply now on those terms - please check
back via
our main web site
Perl - Creating your own ClassesPerl - More Objectsresource index - Perl
Solutions centre home page
You'll find shorter technical items at
The Horse's Mouth and
delegate's questions answered at
the
Opentalk forum.
At Well House Consultants, we provide
training courses on
subjects such as Ruby, Perl, Python, Linux, C, C++, Tcl/Tk, Tomcat, PHP and MySQL. We're asked (and answer)
many questions, and answers to those which are of general interest are
published in this area of our site.