in reply to Really Writing Object Oriented Perl

We write a lot of Perl code where I work, and we write a lot of OO Perl in the sense that we use bless and call methods on objects and classes a lot. But I'm starting to realize that we are Perl developers writing OO Perl in much the same way as a C programmer writes Perl, if that makes sense.
<rant>

Unfortunately, this makes all too much sense. Perl's OO system is really just a thin veneer over the module system and reference types, which really are just the primative building blocks for a real object system. This is not really all that uncommon though, many languages made the move from structured programming (modules, abstract data types, etc) to OO by similarly enhancing existing features. But as the 90s moved into the 00s and Java became every managers dream come true (and many a developers nightmare) the idea of "True" and "Pure" OO became more important than an OO tacked-on to an existing feature set. To be honest, Perl 5 is behind the times on this, Languages like Python and Ruby, which have much more complete OO systems are really making Perl 5 look bad (at least IMHO). Sure, we have TIMTWODI so we can do our OO any way we want, but in practice this has lead to lots of incompatible approachs and extreme work arounds like Inside-Out classes. If you dont believe me you need only see all the crap people are talking about Perl on the Bugzilla wiki. So much of the "Cons" being brought up are not really cons, but bad usage patterns and misunderstandings of features. And while I really hate to say it, it is my opinion that this is really a case of "TIMTWODI gone bad". A lack of any kind of OO "Best Practices" (and no I do not mean TheDamian's book) is hurting Perl. But anyway enough ranting ...

</rant>
I'd love to hear recommendations on what other resources people have found useful for learning how to better apply OO techniques in Perl.

Practice, practice, practice. There are many good OO books out there which teach OO technique (many already mentioned by other posters), but they are no substitute for actually writing real-world code, and even more importantly, maintaining and extending that same code. The cycle of writing and refactoring of an OO codebase over several years has taught me more than any book ever could.

-stvn
  • Comment on Re: Really Writing Object Oriented Perl

Replies are listed 'Best First'.
Re^2: Really Writing Object Oriented Perl
by Joost (Canon) on Jun 01, 2007 at 20:57 UTC
    I agree. IMHO there's one thing that would help this whole situation: there should be a default, modern, easy to use OO framework/library that's recommended for serious work by the majority of "the perl/OO community" (if there is one).

    Something that:

    • Can subclass any other class that's using bless() the right way with any reference type. (I.e. it should use the inside-out fields technique)
    • works with threads (and fork() emulation on windows) - won't use reference addresses to index fields.
    • works with threads::shared - allows you to share objects across threads with minimal fuss.
    • works with XS extensions and allows for easy mixed perl/XS classes/hierarchies.
    The only thing I can think of is Object::InsideOut, though it could use a simple tutorial, some XS helper functions and possibly a less cluttered interface. Other suggestions are welcome.

    If the community can decide on some default library like that, it should be put in the core.

    I know the tendency is to keep as much as possible out of the core, but a default good OO layer (i.e. not Class::Struct) is just plain needed to be able to write good OO perl. It really is too much work to write reliable OO perl without using external modules.

      There's a small but (I hope) steadily growing ressource about OO on PerlMonks: Anno's meditations, replies and questions.

      While his intentions might be different, I perceive his as an effort to implement OO requirements as close as possible to or into the perl core, with what means perl itself already provides. Following this road one day we might not only have the basics needed to implement an OO system in perl - functions as methods, packages as classes, references, bless, ref and so on - but a robust OO system at the core level, not just tacked-on OO implementations in disparate arbitrary and sometimes redundant or contradictory modules on CPAN.

      OO is "magic" - and the perl sense of "magic" fits; I am looking forward to OO related "Magic Virtual Tables" (see perlguts for those) and handling code, either in the perl core, or in some XS extension provided along with the core.

      Anno's inside-out iplementation via magicext seems to meet all the requirements you have outlined so far.

      A lot of fuzziness will have to be discussed and cleaned up to meet that goal - first thing that comes to mind is the ambiguous use of package, module and class - they are often used as synonyms, but address very different aspects needed for a robust OO implementation; then method lookup...

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
        Thanks for that link.

        Anno's solution looks pretty good to me, but sharing objects across threads doesn't work "out of the box". It might be fixable but my perl/threads knowledge is pretty basic.

        Question: is there any hook to catch that an object is shareable (i.e. shared() is called on it) or does the call to CLONE specify that somewhere? I can't seem to find any decent documentation on CLONE().

        XS hooks seem to be very straightforward to implement with this technique. Much easier than with inside-out objects, anyway.

Re^2: Really Writing Object Oriented Perl
by aufflick (Deacon) on Jun 02, 2007 at 13:03 UTC
    I don't think it's a matter of "making Perl look bad", it depends what you're looking for.

    If you're looking for "everything is an object and all actions are methods" language then Ruby or Smalltalk are your best choices. And *very* fine languages both of them are Perl doesn't match that, neither does Java, Python or C++.

    If you're looking for a good-performing byte-compiled language with no manual compile step, Perl and Python fit the bill, Java and Ruby do not.

    If you're looking for a language where you can read and modify many aspects of the runtime engine, then Perl, Python, Ruby and Objective-C will suit you, Java and C++ won't.

    If you're looking for a language that lets you use aspects of functional, OO and Quantum computing, and you want full closures and continuations, you're going to have to bleed at the edge with Perl 6.

    That last one was a bit tongue in cheek, but I think you can see where I'm going. Of course if you want to use certain products then your choice is made for you - and it's simply a matter of whether you can stomach the language. Want a pre-built continuations based web framework? You need Seaside and that means Smalltalk. Want an open source eLearning web system with every function you could think of and an active developer community? You probably want .LRN (AOLServer/tcl/plpgsql) or Moodle (php).

    I really hope that language wars can become a thing of the past, that good languages can prosper on their merits, and bad languages can be contained to legacy systems that were started by developers who didn't know any better...

Re^2: Really Writing Object Oriented Perl
by shmem (Chancellor) on Jun 05, 2007 at 11:43 UTC
    If you dont believe me you need only see all the crap people are talking about Perl on the Bugzilla wiki. So much of the "Cons" being brought up are not really cons, but bad usage patterns and misunderstandings of features.

    That "crap" stems from avatraxiom's journal, and hidden in the comments there's one that sets some bits straight - but the wiki wasn't updated accordingly...

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}