|
neshura has asked for the wisdom of the Perl Monks concerning the following question:
⭐ (object-oriented programming)
There are many articles and essays that say that Perl isn't "really" object-oriented. Is this true, and does it matter?
Originally posted as a Categorized Question. |
Re: Why is it said that Perl does not implement true object orientation?⭐
by chromatic (Archbishop) on Apr 21, 2000 at 01:09 UTC
|
The purist who says this is quite correct -- it is possible to write workable Perl programs that use no object oriented features at all.
The pedant who says this is mostly correct -- Perl was not originally designed as an object oriented language.
The pooh-pooher who says this is uninformed -- Perl's object oriented features are powerful, elegant, simple, and incredibly Perlish.
When it comes down to brass tacks, not everything is an object in Perl. There are native types (scalars, arrays, and strings), functions can exist independent of classes, and very little from any programming discipline is rigidly enforced (or enforced at all). If you're into that sort of thing, Smalltalk is a real object oriented language and most other languages aren't.
(Those of us who actually do real work with OOPerl now and then will continue doing real work, no matter what they say.) | [reply] |
Re: Why is it said that Perl does not implement true object orientation?⭐
by merlyn (Sage) on Apr 26, 2000 at 03:30 UTC
|
Perl has "primitive" data types that cannot be used as base classes nor given new methods. This puts it in the OO class with Java and C++.
Eiffel and Smalltalk and Python are better at pure-OO because they don't have "primitive" types. | [reply] |
Re: Why is it said that Perl does not implement true object orientation?⭐
by ariels (Curate) on Aug 20, 2001 at 16:42 UTC
|
As seen above, it all depends on what you want in your OO programming language. Here's another feature that Perl is missing: proper inheritance of data members (not just functions!).
Perl has no safe way of storing instance variables of your objects. The canonical way to do this is to make your objects blessed hash refs, keeping the instance variables in hash entries. I'll analyse that case, because it's the most common, and because other methods suffer from exactly the same problem.
But what happens when you try to inherit? You have two classes using keys in the same hash. The inheriting class might not know which keys are used in the base class. And if both classes try to use the same key to refer to instance variables they consider their own, trouble is certain.
Say you have a Crypto class, which does some cryptographics. Internally, Crypto reads from a file. So it stores a filehandle in the _fh key of the object.
Now I come along and write the LoggedCrypto class, which inherits from Crypto but also keeps a record of something. I'm writing to a file, so I guess it will be a good idea to store the log file's filehandle in the object's _fh key. Remember that keys beginning with an underscore are meant to be private, so it's "good" that I don't know this key is already in use!
Predictably, havoc ensues. Contrast this with (for instance) C++, where private instance variables just aren't visible from outside their class!
Multiple inheritance makes everything much worse. Now I have several completely independent classes, and I try to use them together by saying
package Derived;
use strict;
use BaseA;
use BaseB;
use BaseC;
use var qw/@ISA/;
@ISA = qw/BaseA BaseB BaseC/;
sub new { # arrange for proper construction...
# ...
}
(Writing new in this case is also non-trivial, and will in general require that the Base.* classes have special auxiliary methods for construction.)
BaseA, BaseB and BaseC all expect (and deserve!) that their instance variables be kept separate. They're not.
How can we get around this? One way is to prefix our keys with our package name. Then we have keys _Crypto_fh and _LoggedCrypto_fh, and no clashes. But that's cumbersome and a maintenance nightmare (imagine renaming LoggedCrypto to Crypto::Logged). Another problem is that you cannot use a (think "protected") instance variable without knowing the exact point on the inheritance hierarchy which "owns" it. That makes changing the hierarchy (e.g. splitting the base class into 2 inheriting classes) nearly impossible.
This problem is real.
| [reply]
[d/l] |
Re: Why is it said that Perl does not implement true object orientation?⭐
by Perlmage (Acolyte) on Apr 21, 2000 at 00:45 UTC
|
Usually, the people who say such things confuse 'object-orientedness',
which is a programming methodology, with one or more
implementations of that methodology.
Perl is not C++ or Java, of course (which are the two
languages that are most often touted as the examples of 'true'
object-oriented languages by the naysayers), so it seems unreasonable
to assume that Perl should follow one or the other's ideas
of what object-orientedness is. I suppose that Eiffel enthusiasts
could feel that C++ doesn't support design-by-contract natively,
and so isn't a 'real' object-oriented language, either.
Just rest assured that despite people's claims that
"Perl's just a scripting language", there are many of us
who develop object-oriented Perl every day.
| [reply] |
Re: Why is it said that Perl does not implement true object orientation?⭐
by Anonymous Monk on Mar 27, 2003 at 21:23 UTC
|
Object Orientation is implemented in a language
for two reasons: reduce code clutter and catch
programmer errors. In the first sense, Perl's
OO works fine. In the second, core Perl lacks
compile-time object type checks. Think of this
as "strict" for checking argument types and
return types, before the program even runs. Java
and C++ do this. It is both handy and cumbersome.
Forcing it on the programmer leads to large
extentions to the language (C++ templates)
or else hacks to bypass it (the Java Vector
only stores objects of type "Object", meaning
any object, which throws away all type information). Rest assured, Perl 6's spec
makes it available - optionally. | [reply] |
|
|
Well, I think that Perl5 OO is very good and can make everything that a OO should, with everything that Java has (since Java "want" to be 100% OO). Much programmers like to say that for real OO you never can do a global variable. Other says that isn't OO if you haven't types for variables.
Fisrt, in Perl you have global variables because Perl have a concept that you can do everything that you want, and you are not forced to use or not OO, or any thing. About the types for variables, well, Perl don't want to confuse the developer with variable types or conversions, you just need to think about the algorithm. And the variable types are there, at least for C/C++, because they are converted to assembler instructions (to than be machine codes), and the CPU need to know that before. And you win speed with the type (but in Java not, at least should), since you (well, the compiler, or interpreter, or VM) don't need to always check what type of variable is that, and what I need to make to work with 2 different types, who do that is the developer. But every one that already have worked with XS and internal Perl variables saw that a SV (scalar variable) have some states (Flags), like integer, double, string, utf8, etc... and this is a kind of type for variable, but Perl do this automatically for you, including the conversions. But the most interesting thing of the Perl5 interpreter is the speed, that is very good, and Perl5 is the fastest scripting language that have, and even with not "typed" variables the memory management is the best, in cases best than C/C++. Saw some time ago a good article about language comparations.
About the C++ OO, well a lot of peoples say that C++ is not a real OO too. But I think that they are confusing OO with Java, or other thing. OO is a concept of how to organize an app, including the reuse of code. If you have this concepts you can make beautiful classes in C++. And wxWindows is there to show that, one of the best OO librarys in C++. For who don't know what is wxWindows, is a full portable C++ GUI library, that works on Linux, Mac, Win32, Motif, WinCE... For Perl take a look at wxPerl, that is wxWindows linked to Perl.
Just in case:
http://www.wxwindows.org
http://wxperl.sf.net
Final words: Who say that Perl OO is not a real OO just don't know Perl, and this is the problem, who say bad things about Perl always don't know and don't use Perl. Just think something about what Perl is. Well, I use a lot of languages, work with a lot of peoples, talk with a lot of PhD at computer cience, and saw that much peoples spend much time talking about theories, defending the theorie just by the theorie, but forget that the objective of the theorie is to be good at pratic. You can have a language that is good at theorie and forgot the pratic, the final objective of everything. But theorie is still important to have a good vision about all, and is from there that good ideas come. ;-)
... In other words, theorie is like talk about sex without do sex, but camasutra is still interesting. ;-P
Graciliano M. P.
"The creativity is the expression of the liberty".
| [reply] |
|
|
| [reply] |
|
|
