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.