Re: maintenance of overriding subprograms

[jsa@alexandria.organon.com (Jon S Anthony)]

In article <EG8tAB.Et5@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <34145A2F.3659@pseserv3.fw.hac.com>,
> W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
> >If your names are well-chosen, and your hierarchy well-designed, 
> >wouldn't it be unnecessary (except for the occasional extreme case)
> >to hunt down a lot of other stuff to understand the item at hand?
> 
> I don't think so.  If I see:
> 
>     package P is
>         type T is new Some_Parent with ...;
>         procedure Foo(X: T);
>     private
>         ...
>     end P;
> 
> How on Earth am I supposed to know about the 17 primitive operations of
> type T?

Right.  You can't without looking them all up.  And it gets a _lot_
worse with MI.  This is just the old problem of OO (typically swept
under the rug by OO fanatics) that it can cause all sorts of
maintenance problems.

> >Conversely, if one has to study all the ancestors in great detail
> >to do anything with a particular descendant, haven't we lost much of
> >the reduced work alleged to be acheived by inheritance?

IMO, reducing work is not and never really has been a benefit of OO.
That's not what its good for.


> Well, not really.  For example, think of all those clients of the
> *parent* type that happily use the derived type without even *knowing*
> about it.

And possibly shooting themselves in the foot and generating all sorts
of maintenance nightmares to where the whole thing collapses under its
own bloated opaque weight.


> It depends who's doing the "alleging", I guess.  It ranges from "OOP
> is a useful tool" to "OOP will cure all the world's ills".  ;-)

To "OOP is outright dangerous" if not handled very carefully.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari