Hmm, I disagree with pretty much all of that. I love the simplicity and flexibility of perl's object model, and I've written a lot of OO perl code using inheritance.

Note that perl does cache the method-lookups. I tend to write code initially in the simplest possible way and worry about optimisation only when it becomes necessary to do so: while I regularly do come up against a need to optimise eventually, the method-lookup overhead has never been a significant factor at that point ⁽⁰⁾. Maybe I've just been lucky.

I have not had problems with child/parent disagreements - it is usually pretty clear to me when the child needs to call $self->SUPER::method(@_). Maybe I've just been lucky, but I think this is also a question of class design, and of course of documentation - it is vital for parent classes to document what children may, must, or must not do. ⁽¹⁾

Abstract classes I also use a lot of, but I've always considered it adequate to have the abstract class die at runtime if a method gets called that should have been overridden by a concrete child. This has never caused me any significant problems - and certainly not in production code - but maybe I've just been lucky.

I don't tend to have any data that parent and child agree to use - my attributes are accessed through attribute methods, and that method is the _only_ thing that knows how to find the data. Even within other methods of the parent class I call the attribute method, which (among other things) makes it really easy to change the implementation. I've never found the need to distinguish between child classes and other callers in such attribute methods, but maybe I've just been lucky.

It probably helped that before Perl I'd only ever tried to do OO design in C++, and hated the complex inflexible approach there - I think perhaps that allowed me to develop my approach to OO concentrating on Perl's strengths rather than trying to force Perl into the mould of some existing methodology it might be less suited for.

Hugo

(0) That's not entirely true, but the only examples I can think of were standalone scripts solving a mathematical problem using a deeply recursive solution, with an object representing the problem parameters. In those cases it wasn't particularly method lookups that were a problem - even the overhead of a straight subroutine call was significant enough to avoid if possible.

(1) The only time this has caused me a problem is when one class is auto-generating methods (I do this a lot) that use SUPER into another class, which I haven't needed that often but becomes a real pain when I do. I've worked around that in my current work application using string-eval to generate the methods directly in the appropriate class, which is ugly, but works ok.

I have not had problems with child/parent disagreements

Yes, it's always possible to get around the problems. I only want these things to be automatic. I used to think bless should be automatic, but now I'm not so sure (it does provide a lot of flexibility). But calling a parent's destructor should definatly be automatic.

considered it adequate to have the abstract class die at runtime if a method gets called that should have been overridden by a concrete child

I think you genuinely have been lucky here, though lucky in a way that almost everyone else will also get lucky. Consider a child class that implements everything except one little-used method left unimplemented in the child that nobody notices for years, long after the orginal programmers of the parent and child classes have left. Since the checking is done when the method is called, nobody notices it. One day, somebody notices this obscure method and decides to use it. Oops, runtime error. Cracks appear in the earth's surface. The sun explodes. All die.

Most of my OO background comes from Java, which may not have the best object system, but is is very clean compared to C++.

Most of the things I consider broken in Perl's object system are being fixed in Perl6, along with a few other parts of the language that bug me (like parameter passing to subroutines).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Since you've invoked my name, some clarification on some things that my position on this are not... I would not say you should never use inheritance in Perl.

And I vehemently disagree that "Inheritance is...a primary reason to have an object system in the first place". I think inheritance sucks in some important ways and these are made worse in Perl. And I also think people tend to way over-value inheritance.

So I think one will be happier in the long run if one considers inheritance (of more than just interfaces) to be more of a "last resort" than the feature of OO. This is even more true in Perl since Perl doesn't really have interfaces (much less really supporting inheritance of them) and Perl's clunky OO system makes inheritance even more problematic in general.