neshura has asked for the wisdom of the Perl Monks concerning the following question: ⭐ (object-oriented programming)
Originally posted as a Categorized Question.
|
---|
Replies are listed 'Best First'. | |
---|---|
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 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 | |
| [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 | |
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 (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 | |
| [reply] |
by gmpassos (Priest) on Mar 28, 2003 at 08:36 UTC | |
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: 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. | [reply] |
by IlyaM (Parson) on Mar 28, 2003 at 13:16 UTC | |
-- | [reply] |