From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,896d86ef3723978c X-Google-Attributes: gid103376,public From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: maintenance of overriding subprograms Date: 1997/09/10 Message-ID: <5v5ns4$hrf$1@trumpet.uni-mannheim.de>#1/1 X-Deja-AN: 271232165 Organization: --- Newsgroups: comp.lang.ada Date: 1997-09-10T00:00:00+00:00 List-Id: 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