brian moseley <[EMAIL PROTECTED]> writes:
> > 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?
Well, not entirely. It's like the difference between using symbolic
references and not using symbolic references. Sure, they work, and
can be powerful, but they can also be obfuscating and a little
obscure. I don't like tossing objects around and expecting them to
adhere to some unknown interface that they aren't derived from. The
only real difference at the code layer is ->isa, but that's not a
large benefit; instead, it's at the design level. Making an abstract
base class is very simple, and there's no performance overhead for a
class to derive from it if it implements all of its own methods (and
one could argue if there -is- common code that can be implemented in
non-abstract base methods then there is even more benefit in having an
abstract base class).
Basically it's "enforcing" a tiny bit of type data in an otherwise
more or less typeless world.
Code is cleaner if you can say "the nth parameter is derived from the
base class Foo::Bar" as opposed to "the nth parameter is an object
that must support the baz, blah, foop, and fitz methods that accept
parameters in the following way..."
> 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.
Well, you could always do something like:
my Foo::Bar $x = shift;
This doesn't really gain anything now, but it makes things a bit
clearer what exactly is going on. Future perl's may optimize this
(right now, if I recall, it only optimizes in the case of
pseudohashes).
Sadly, you'll never really be able to get compile time type
verification in perl (at least, in perl as it stands today). Even the
above syntax is only a promise to perl for possible optimizations and
not a request for perl to enforce the type of whatever shift returns.
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
