•Re: Perl - Is it an OO Language
by merlyn (Sage) on Aug 26, 2002 at 17:44 UTC
|
I have not seen any thing on polymorpism in Perl.
You can't have inheritance without at least one level of polymorphism: dispatch on the target object!
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?
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.
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
| [reply] |
|
| [reply] |
|
| [reply] |
|
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.
| [reply] |
|
| [reply] |
Re: Perl - Is it an OO Language
by BrowserUk (Patriarch) on Aug 26, 2002 at 22:06 UTC
|
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.
What's this about a "crooked mitre"? I'm good at woodwork!
| [reply] |
|
| [reply] |
Re: Perl - Is it an OO Language
by dreadpiratepeter (Priest) on Aug 26, 2002 at 18:05 UTC
|
To paraphrase Larry, Perl is an OO Language, for some definition of OO Language.
The short answer to your question is: yes, Perl supports all the required features of an OO Language.
For the long answer read Damian Conway's, "Object Oriented Perl", in which he exhaustively covers the subject.
It sounds to me like neither of Guru A or Guru B know enough about Perl to answer your question. Guru B is honest enough to say so, Guru A gives a flip dismissal. If Guru A knew Perl he would know that it has many uses outside of a "glue" language.(And if he knew both Perl and OO he would know that Perl is an OO Language).
-pete
"Pain heals. Chicks dig scars. Glory lasts forever." | [reply] |
Re: Perl - Is it an OO Language
by Zaxo (Archbishop) on Aug 26, 2002 at 18:11 UTC
|
{ my $secret = qr/^word$/;
sub guess {
$_ = shift || '';
m/$secret/;
}
}
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
| [reply] [d/l] |
Re: Perl - Is it an OO Language
by Abigail-II (Bishop) on Aug 27, 2002 at 09:22 UTC
|
I don't think it's right to call a language OO if it supports
inheritance, abstraction, polymorphism and encapsulation. You
should judge how easy it is, and how easy it is to do it right.
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
| [reply] |
|
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
| [reply] |
|
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.
| [reply] |
|
|
|
()-()
\"/
`
| [reply] |
|
| [reply] |
|
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
| [reply] |
Re: Perl - Is it an OO Language
by Django (Pilgrim) on Aug 26, 2002 at 20:57 UTC
|
The various methodologies of programming are admittedly a widely unexplored field for me. From that viewpoint - experimenting, not being fixed to one or another - I'd like to point out one outrageous strength of perl: its flexibility - TMWTDI! You can use perl the way you choose or as required by the situation. You might code in linear, orthogonal or even diagonal ways. Just another quote from the Camel: "In a nutshell, Perl is designed to make the easy jobs easy, without making the hard jobs impossible." | [reply] |
|
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.
()-()
\"/
`
| [reply] |
|
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
| [reply] |
Re: Perl - Is it an OO Language
by Vennis (Pilgrim) on Aug 27, 2002 at 07:39 UTC
|
At the end, you need a programmer that is OO. I personally think a good programmer can create an OO program in a not 100% OO language.
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).
| [reply] |
Re: Perl - Is it an OO Language
by Anonymous Monk on Aug 26, 2002 at 20:58 UTC
|
Perl makes OO simple. Some people have a problem with that.
OO was suppose to make programming simplier, too.
I'd say that Perl is not a complicated OO programming
language. "GURU's" love to make things more complicated then
they actually have to be so I can under stand why GURU 1 & 2
don't want to use Perl. | [reply] |
|
<embarrassed grin>
DOH! I meant UNcomplicated OO programming language.
</embarrassed grin>
| [reply] |
Re: Perl - Is it an OO Language
by Anonymous Monk on Aug 26, 2002 at 18:10 UTC
|
Perl's OO encapsulation is weak at best. You can not just subclass
an existing class without examining the parent class implementation.
| [reply] |
|
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
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 | [reply] [d/l] |
|
| [reply] |
|
class A {
int ma;
void printit();
A::A() : ma(666) {}
};
==toto1.cc
#include "iostream"
#define class struct
#include "toto.h"
main() {
A a;
std::cerr << a.ma << "\n";
a.printit();
}
==toto2.cc
#include "iostream"
#include "toto.h"
void
A::printit() {
std::cerr << ma << "\n";
}
===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
$
| [reply] [d/l] [select] |
|
|
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
| [reply] |
|
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.
| [reply] |
|
|
|
|
|
|
| [reply] |
Re: Perl - Is it an OO Language
by pray (Initiate) on Aug 27, 2002 at 16:32 UTC
|
I have read and used perl as an OO language, and can understand the functionality over reusability arguments. Whilst I find it a problem on some levels that I have not yet found a internal implementation of 'public' and 'private' methods, this does not detract from the fact as stated in many of the messages previous that Perl 'can' be programmed in an OO fashion, which is to say that the language meets the criteria irrespective of whether you use it as a functional, procedural or 'glue' language.
I suppose if you wanted to get truely detailed you could claim that OO isn't a true paradigm as many books on the different programming paradigms have claimed that it was simply a highbrid more ordered procedural language. But I believe it is a paradigm in itself and although perl fits into this paradigm it is important to note that it can also fit in other paradigms too.
Surely the reusability issue is more to do with less than accurate documentation and not following proper 'Object Oriented Design' methodologies when designing the framework, which should ideally be done as an abstract to the language, making the reusability an issue of better OOD rather than the more subjective language (Perl for example) selected for the task.
Just my thoughts.
(Oh and shoot GURU_02 or atleast s/GURU_02/Unfounded_Opinions_Guy;)
--pray.
| [reply] |
|
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. :-)
| [reply] |
|
GURU_02 was the one who didn't have an opinion on Perl's OO.
| [reply] |
Re: Perl - Is it an OO Language
by richardX (Pilgrim) on Aug 28, 2002 at 21:11 UTC
|
Choosing a language just because of it's OO abilities or lack of is like picking a girlfriend because she has a nice chassis. There is more to her than one aspect.
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 | [reply] |