Re: maintenance of overriding subprograms

[mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]

jsa@alexandria.organon.com (Jon S Anthony) wrote:
> > 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.

This particular problem could be solved by following a well-established
design principle of Ada (which was, IMO unfortunately, not done in this
case), namely to favour ease of reading and clarity over ease of writing:
Simply have each subtype define _all_ its methods explicitly, making any
calls of supertype-methods explicit (something similar could be done for
instance variables of the parent, too). Along with this, clearly separate
subtyping (type compatibility) and inheritance (implementation), where
the latter may only be used to adapt existing implementations as fields
(subobjects) for new types, which results in a programming style more like
delegation, though still allowing to redefine some (maybe a restricted subset)
methods of the adapted type. Generally there would be no relation between
the types of the new type and whichever types it may adapt for implementation,
though where appropriate, both may of course be declared to support the same
interfaces. This results both in more explicit (and thus hopefully clear)
relations between various types/implementations, and in better decoupling.
Single inheritance (i.e. adaption of subobjects) would be sufficient; however,
adaptions for various subobjects and methods for the resulting new type should
be able to freely call each other.

For some similar ideas, see Michael Franz' paper on the language Lagoona,
http://http://www.ics.uci.edu/~franz/PDF/Lagoona-ics-tr-96-40.pdf

> > 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.

That's why subtyping should be constrained to be "safe for the innocent".
For an excellent (IMO) approach to this, see the paper of Barbara Liskov
and Jeannette M. Wing on "Family Values: A Behavioural Notion of Subtyping",
http://www.dstc.edu.au/AU/research_news/odp/typemgmt/related_work/
                                                       behav_subtype.html
(the last two lines are supposed to be one URL).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>