Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re: Re: Never

by hv (Parson)
on May 13, 2003 at 16:41 UTC ( #257814=note: print w/replies, xml ) Need Help??

in reply to Re: Never
in thread Never-to-use Perl features?

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 (0). 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. (1)

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.


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

Replies are listed 'Best First'.
Re: Re: Re: Never
by hardburn (Abbot) on May 13, 2003 at 16:54 UTC

    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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://257814]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (1)
As of 2018-07-21 07:53 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (445 votes). Check out past polls.