I have not seen any thing on polymorpism in Perl.

So, the answer to this is a simple yes.

However, you can have multiple dispatch using Class::Multimethods, so the answer is even more far ranging than first seems.

Is Perl a true or psuedo OO Language?

Perl is as much of an OO language as C++ or Java or Python. Ruby and Smalltalk and Eiffel are a bit further up the scale, since they're actually "pure" OO. Perl, C++, Java, and Python are "hybrid" OO, with primitive pseudo-objects and pseudo-classes that cannot be extended or subclassed or introspected.

-- Randal L. Schwartz, Perl hacker

Is Perl a true or psuedo OO Language?

Well, to answer that, you'll need to define "true" and "psuedo (sic)". Perl's OO support is decent, and Perl 6 will only be getting better.

I realize now that my question is subjective. Here is a better question then

Does Perl have the four attributes that GURU_2 describes

• Abstraction
• Polymorphism
• Encapsulation
• Inheritance

Kristofer

I don't know what "GURU_2" is, but the answer to those is "yes", if you hadn't already figured it out from the previous answers in this thread.

-- Randal L. Schwartz, Perl hacker

I'm confused a little bit as to your grouping of Java and C++ in the same tier of OO languages. I'm not a Java expert, but am I correct in assuming that the only non-OO aspect of Java in that definition is its continuance of primitive data types? I can't recite all of the classes in the the Java 2 API, but I haven't come across anything yet that cna't be extended or subclassed or introspected... All in all, I agree with your posts here wholly, except that I would break up that tier and put Java a little higher, as it is possible to write purely procedural C++, which is just not an option in Java.

Yes, the need for "primitive types" and "boxing" is one of the things that really takes Java out of the "pure OO" category.

-- Randal L. Schwartz, Perl hacker

If I were you, faced with Guru2's opinions, I would ask him for

• His definition of a real OO language and how it fits his 4 criteria.
• What, in his opinion, Perl lacks by way of those same criteria

Take notes and come back and post his answers.

You will then likely as not, get a refute (or two:) of his criticisms for Perl. And a refute of his choice of true OO (unless its Smalltalk, Ruby or Eiffel).

Whence you have heard both sides, you may then be better placed to make your own decision as to what is important.

It is possible, though quite difficult, to write OO in C.

It also possible and actually quite easy, to write extremely bad code in the true OO languages.

I once had the misfortune to have to try and unpick the dying skeleton of a Smalltalk project in order to reverse-engineer as far as possible the specification of the bits that worked prior to a re-write in another language. The guys that wrote it were, well lets just say they took the notion of re-use to the extreme, inheriting from anywhere that vaguely did something that they needed to do. The result was a tortuously, convoluted mess.

Like most of the other "paradigm shifts" that have gone before it, OO isn't the holy grail, it's just another method of designing software.

Some language support this concept by providing syntax and semantics, along with class libraries, that lend themselves in the implementation of projects designed from the OO perspective.

Some languages--C++ for instance--have tried to force fit these concepts and ideals upon their predecessors, and despite having ridden the tide of OO-isms rising popularity, have never quite succeeded in their goals. The C++ templating mechanism for polymorphism is one very good example. Leaving the ability to cast from object types to primitive types is another. I seen and even written C++ that used casts to bypass certain restrictions imposed by the compiler. I hear the OO purists around world take deep breaths in shock and feel the wind of their wagging fingers, but the piece of code I am thinking of is still in use today some 8 years after it was written, and doing sterling service despite it's 'cheats'.

I have also seen and contributed to code written in a language called BLISS (a C-like system programming language) that could, if you squint your eyes enough, be called OO in its design, despite having predated the OO-phenomena by some years.

In the end, it doesn't really matter how much the language or the tools try to enforce the OO paradigm. If the designers & programmers using it don't really understand, or take the time to do their jobs right, then you can still end up in a mess. Alternatively, if the design is well thought through , and the implementation follows the design, the language used is pretty irrelevant.

Whilst the OO purists will argue against it, there are, and probably always will be times when it makes commercial sense (read: cheaper) to 'drift' from the path of true OO-ness in order to get the job done. Provided this is agreed, fed back into the design specs, and well documented, its ok.

Perl allows this. Smalltalk doesn't. I love Smalltalk at the intellectual level, but sometimes trying to get it to do what you want it to do can be a real pain in the ..er..well, you know. That said, I haven't even begun to explore Perl's OO side. I'm having to much fun exploring it's other possibilities.

Tempting, the dark-side is.

Wisely spoken!

Encapsulation is done with closures:

{   my $secret = qr/^word$/;
    sub guess {
        $_ = shift || '';
        m/$secret/;
    }
}
[download]

Polymorphism is done with use overload $op => sub {};, or with overriding functions. There are lots of examples in the link. Both mechanisms respect inheritance.

Don't worry about 'true' OO. That is a chimera cooked up by religionists of various languages to put down other languages. Many take the ability to do something besides OO as disqualifying. OO is a methodology for design and structure. It's not the only one.

Object Oriented Perl by TheDamian is the primary reference book. Perl's perlboot, perltoot, perltooc (AKA perltootc in 5.6 - thanks, demerphq, for pointing that out), perlbot are in the distribution as tutorials, along with perlref, perlobj, perlmod as references.

After Compline,
Zaxo

You can do all four in C and Pascal, but most people will agree those languages shouldn't be labelled OO. In Perl, it's easy to make something that smells like OO. It's easy to make something that has a variable left of an arrow and a method to the right the arrow. But that doesn't mean you have done it right.

You can do inheritance, abstraction, polymorphism and encapsulation right in Perl. But it's surprisingly hard in Perl to do all four right at the same time. You have to do most of it yourself - the language isn't helping you much. In fact, it tends to work against you. You won't find the right way in the documentation, that just shows you the quick and dirty (wrong) way. It's every (wo)man for him/herself, making it hard to use or understand someone elses code.

If all you care about is writing quick glueing scripts, this OO mockup works handy-dandy. Just as GURU_01 says. But to do it right, Perl is just one small step above C.

I won't call Perl OO for the same reason I won't call Perl a functional programming language. Not because it's impossible to do, but because the language doesn't give you enough tools to make it easy.

Abigail

This is the answer I was looking for.

I posed BrowserUK's bullet points to GURU_2. He then showed a Java example to me while outlined the four tenents he described in one section of code. It was 6 lines total and they were all easily read. Over the course of his demonstration he also said nearly verbatim what Abigail-II said here, and what ignatz said as well.

++ Abigail-II, BrowserUK, Merlyn, ignatz, Zaxo and others for your insight and help

Thank you very much,

Kristofer A. Hoch

I draw your attention to charnos and merlyn's points above how even Java has jumped out of the "OO paradigm" to satisfy its own necessities.

I find it fascinating that Guru_2 can write 6 LoC in java once you've done the importing and class declaration is there really that many lines left ;)

Jokes aside, of course the lines of java was easy to read, many of the shortcuts in Perl do make the code less readable but removes unnecessary lines in the process and the readability over effeciency is a whole different debate that rages on.

I would like to point out though that on the whole perl is run from the script and would ask you to try and read the java .class file that the computer compiles. Alternatively look at the tremendous number of issues surrounding a Java JITC (Just In Time Compiler), as many of these are memory inefficient and would quite hapily get kicked from pillar to post by perl. Don't get me wrong I find programming in Java fascinating and enjoy using it for different things, you could sit here forever pointing out the pro's and con's of each language when compared against each other.

Do something unholy and post the lines of Java up that GURU_2 used in his example, and see what people post back with for a perl equivelent.

--pray.

Very well said.

If Perl was "OO" Ruby wouldn't exist.

()-()
 \"/
  `                                                     

Not true. Ruby exists primarily because existing scripting languages didn't have good Japanese support.

But it is possible that if Perl's OO was better then there might not be a viable niche for Ruby in the English-speaking world.

You won't find the right way in the documentation, that just shows you the quick and dirty (wrong) way.

What is the right way?

—John

Ahh, flexibility: Perl's greatest strength and its greatest weakness. When it comes to OO programming, there has to be a distinction between how flexible it is to do something and how flexible it is to use.

It is very easy to do OO in many different ways in Perl. Bend over backwards and you can easily tie yourself up into a pretty OO pretzel. No two Perl gurus seem to be able to agree on what is the "best" way to do it. ("Cargo Cult! Cargo Cult!") In these terms it is "flexible."

The fact the OO implementation in Perl is so "flexible" means that the resulting classes are very inflexible in terms of reusability. They don't play well with others.

In order for a language to be "OO", there have to be a clear set of rules that all of the objects can agree upon. OO needs flexibility not in terms of how one creates objects, but in terms of how one uses objects. In these terms, Perl fails miserably.

()-()
 \"/
  `                                                     

Sometimes, someone wants to trade flexibility for performance. I would like in perl6 to have a pragmatic mode that indicates that I forsake classes as objects and dynamic inheritance graphs so as to be able to beneficiate of a faster run-time. It would force me to declare the type of every variable.

My dream is to be able to compile such a code to native object code.

A program would start its life very flexible and eventually would be optimized so as to be compilable.

So the TMOWTDI would not apply only to many possible programming style but would also mean that the style of a program will change over its life.

-- stefp -- check out TeXmacs wiki

Like BrowserUk says, a bad programmer can also make a mess with a 'true' OO language. In that way, an OO language is not holy.

The idea behind OO is, as i think of it, to create easily reusable good documented pluggable peaces of software. OO is a way of thinking and not dependable on the tool you use (though the tool can make things easier ofcourse).

<embarrassed grin>
DOH! I meant UNcomplicated OO programming language.
</embarrassed grin>

Perl's OO encapsulation is weak at best

There can be levels of encapsulation. And this may not be a good thing. Acording to Stroustrup in C++ there is one too many. In The design and evolution of C++ page 302 he says In retrospect, I think that protect is a case where "good arguments" and fashion overcame my better judgement and my rules of thumb for accepting new features. Admittedly in Perl there is no level of encapsulation. Object variable members are accessible to anyone but people cannot access one by mistake unlike C++ because in Perl one must explicitly mention the object when accessible a member variable $self->{var}. Perl6 will probably be hoepfully less verbose while still avoiding the C++ potnetial ambiguity: $.var (note the dot that means that a member variable is accessed). In C++, in a member method, you can access by mistake a member variable of the class or a parent class when you thought you were accessing a global variable or if you forgot to declare the lexical variable you use.

Also there is two kinds of encapsulation: forced or not. In perl no one is ever forced to anything. As I said before, there is encapsulation in the sense that no one can unwillingly access object data.

BTW: C++ forced encapsulation is a joke because it is so easy to defeat. It is just a compilation thing, no check at link time:

#define private public
#define protected public
#define class  struct
[download]

Anyway, one must always be careful of language comparaison because one always uses the metric adapted for its favorite language. Judging a language only for its OO-ness is a very restricted view in my opinion.

In fact pure OO language are insanely verbose for the "Hello World" test. One of the perl feat is to scale from oneliners to moderately big programs. In this case, good score in the "pure OO-ness" metric is a _bad_ thing.

Corrected the Stroustrup reference

-- stefp -- check out TeXmacs wiki

C++ private/public is checked at link time. If you compile the code as private, then change the header to read public and compile a client of the class, the problem will be caught at link time because the attributes are encoded in the name.

If you defeat that, it might not work at all because the ordering may change in the layout of the data or virtual functions!

This must be platform dependant because on my linux box with g++ 3.2. I get to link and execute.

John M. Dlugosz. Are you sure of what you say? Sorry about the off topic. ==toto.h

class A {
  int ma;

  void printit();

  A::A() : ma(666) {}
};
[download]

==toto1.cc

#include "iostream"
#define class struct
#include "toto.h"

main() {
  A a;
  std::cerr << a.ma << "\n";
  a.printit();
}
[download]

==toto2.cc

#include "iostream"
#include "toto.h"

void
A::printit() {
  std::cerr << ma << "\n";
}
[download]

===Compilation, link, execution

$ g++ -c toto1.cc -o toto1.o
$ g++ -c toto2.cc -o toto2.o
In file included from toto2.cc:2:
toto.h:1: warning: all member functions in class `A' are private
$ g++ toto*.o -o a.out
$ ./a.out
666
666
$
[download]

Well, you can do it blindly by encapsulation and delegation. But the "weak at best" is a bit far-reaching here, don't you think?

Perl has a complete set of typical OO-operations available, as long as everyone cooperates.

-- Randal L. Schwartz, Perl hacker

I am speaking of Perl's OO encapsulation being weak, and it is. Yes you can acheive various degrees of encapsulation, but at a cost (or in Damian's words, by turning Perl's flexibility against itself). I think saying that Perl's OO encapsulation is 'weak at best' is a fair statement.

Is that can in the same vein as "you can write structured if/while/etc code in assembly language."?

Perl can do a great deal. I think the question is arguing semantics on how much innate support is required to be an OO language.

My design is object-oriented. It's implemented in Perl. QED?

—John

I agree. I don't think the fact that methods are procedures or functions in any way invalidates OO as a "true paradigm". In my experience, OO is about organization and higher-level relationships between pieces of information in a program. How the lower-level operations are done is not part of the "OO paradigm".

That said, once OO in Perl6 gets sorted out, I'd like to hear more about support for contracts, which are just as important in writing tight, well-organized code. :-)

GURU_02 was the one who didn't have an opinion on Perl's OO.

Many clients ask me what the best programming language for business is. I respond that it depends on the goals at hand. A bus and a sports car can both get you to your destination, but if you need speed, then a bus is out classed. If you need to transport a lot of people, then a sports car comes up short. Sure you can make 50 trips in the sports car to balance the one trip in the bus, but why?

Like some of the other Perl posters have said, don’t evaluate a language strictly on OO.

Don’t let the bright shiny objects distract you :}

Richard

There are three types of people in this world, those that can count and those that cannot. Anon