Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Why is it said that Perl does not implement true object orientation?

( #8271=categorized question: print w/ replies, xml ) Need Help??
Contributed by neshura on Apr 21, 2000 at 00:20 UTC
Q&A  > object-oriented programming


Description:

There are many articles and essays that say that Perl isn't "really" object-oriented. Is this true, and does it matter?

Answer: Why is it said that Perl does not implement true object orientation?
contributed by chromatic

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.)

Answer: Why is it said that Perl does not implement true object orientation?
contributed by merlyn

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.

Answer: Why is it said that Perl does not implement true object orientation?
contributed by ariels

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.

Answer: Why is it said that Perl does not implement true object orientation?
contributed by Perlmage

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.

Answer: Why is it said that Perl does not implement true object orientation?
contributed by Anonymous Monk

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.

Please (register and) log in if you wish to add an answer



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others studying the Monastery: (10)
    As of 2014-12-22 08:54 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      Is guessing a good strategy for surviving in the IT business?





      Results (113 votes), past polls