in reply to Abstract Classes

a principal point of an abstract class is that we don't care how subclasses are implemented, provided methods x, y, and z exist

Sure you do; you're forcing them to inherit from an abstract base class and to declare the existence of their methods at compile-time. That's two implementation details that your approach enforces.

Whether that's good or bad, you tell me. :)

One feature that could save a lot of cut and pasted code is support for mixins in the descendant classes. If there's no inheritance of implementation, there really ought to be another way to reuse similar code.

Replies are listed 'Best First'.
Re: Re: Abstract Classes
by hardburn (Abbot) on Apr 28, 2003 at 16:04 UTC

    Good, because without specifying the methods to implement, why have an abstract class?

    My point was that inheriting and checking the existance and signatures (if possible, which doesn't appear to be the case in Perl5) should be the only things abstract classes force on subclasses. Sorry if I wasn't clear.

    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