No, if UNIVERSAL were an abstract class, then the can() and isa() methods would be unimplemented (that is what makes a class abstract -- none of its methods are implemented, the class consists of only a interface definition and no implementation) and you would be required to implement them yourself in any class you build that inherits from UNIVERSAL (which would be all classes since all classes inherit from UNIVERSAL implicitly).

I respectfully beg to differ with this definition of abstract. An abstract class most certainly can provide implementations. Here's what the Gang of Four (Gamma, Helm, Johnson, and Vlissides) have to say on page 15 of Design Patterns.

An abstract class is one whose main purpose is to define a common interface for its subclasses. An abstract class will defer some or all of its implementation to operations defined in its subclasses; hence an abstract class cannot be instantiated. The operations that an abstract class declares but doesn't implement are called abstract operations. Classes that aren't abstract are called concrete classes.

Without the ability to have implementations in abstract classes, you'd need a pair of superclasses to factor common code out of like classes: one for the abstract operations, the other for the common, factored operations. This wastes a class, and makes the class hierarchy one deeper than is really necessary.

Thank you for the clarification.

Sorry for my mistake. When talking about abstract classes in Perl, I don't pay too much attention to detail as the whole concept seems a bit silly to me (defining a simple list of method names as "an interface definition" -- I'm smirking just typing that -- but I'm also repeating myself).

Of course, UNIVERSAL isn't a very good concrete class because you can't properly create objects of type UNIVERSAL.

But I wouldn't call it an abstract class as it doesn't really define a common interface (it implements a couple of helper functions that are never meant to be overridden). You could stretch and call it an abstract class because it doesn't implement new(), but it doesn't define an interface for new() either, so I do consider that a stretch. So it would be an abstract class that has no abstract operations?

Perhaps someone with a big list of fancy OO terms can come up with a term that is a better fit. ("helper", "degenerate", and "catch-all" come to my mind)

        - tye (but my friends call me "Tye")

Thanks tye,
Methinks I was wacked on abstract, pure abstract, virtual, and pure virtual. None of which mean the same things.
_________________
madams@scc.net

              (__)
              (\/)
       /-------\/
      / | 666 ||
     *  ||----||
[download]