On 25 May 2001, Chip Turner wrote:
> My only objection to this (as I stated in another email)
> is that it leaves things largely unspecified. It's
> similar to the old perl problem of passing big hashes
> around; you assume the data is there, but there's no
> real way to find out without checking keys and so forth.
> A simple $foo->isa('Widget::CGIData') can ensure that
> what you're talking to is at least derived from the
> right thing. Just because perl would let you call
> methods on a class not derived from a standard base
> doesn't mean it's necessarily appropriate. An abstract
> base class offers little overhead (especially if you
> override all of the methods) while still giving that
> little bit of insurance about just what you've been
> passed. In a library that conceivably could be used by
> a number of people, such discipline would probably be a
> nice thing, even if it didn't actually buy anything in
> terms of performance or features.
so the only reason you'd provide a superclass is to be able
to do an isa check? in what circumstances do you use this
kind of check? do you apply it to every argument in every
method call? what do you do on failure?
i've been wondering how best to specify interfaces (in the
java sense) in perl, whether or not to make them classes.
possible benefits are type checking (as you've noted above)
and verification of the implementation of methods specified
by the interface. altho if i could get benefit #2, i
wouldn't care about #1, cos i just want to be sure that the
implementing class (or one of its ancestors) declares each
of the interface methods. and i want this verification at
compile time, not runtime.
