Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!hercules!sparkyfs!mckenney
From: mckenney@sparkyfs.istc.sri.com (Paul Mckenney)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <31960@sparkyfs.istc.sri.com>
Date: 31 May 90 18:35:12 GMT
References: <1990May20.154035.15064@axion.bt.co.uk| <54783@microsoft.UUCP> <5121@stpstn.UUCP> <54917@microsoft.UUCP> <480@tetrauk.UUCP> <1990May30.204110.22011@ux1.cso.uiuc.edu>
Reply-To: mckenney@perth.itstd.sri.com.UUCP (Paul E. McKenney)
Organization: SRI International, Menlo Park, CA 94025
Lines: 52

In article <1990May30.204110.22011@ux1.cso.uiuc.edu> render@m.cs.uiuc.edu.UUCP (Hal Render) writes:
>In article <480@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
>>The problem of safe inheritance has been nicely addressed in Eiffel in the form
>>of assertions, the most important of which is the "class invariant".  For those
>>who don't know Eiffel, this is a list of boolean expressions in a class whose
>>truth can be tested at run time every time a routine in the class returns to
>>the caller.  A failure of course generates a run-time exception.
>>
>>With inheritance, the invariants of all parent classes are also checked, i.e.
>>invariants are inherited, and can only be added to, not replaced.  This allows
>>an inheriting class to overide a routine, but it must still conform to the
>>invariant.
>
>Although class invariants are A Good Thing, I think that a more direct 
>mechanism that prevents a method from being redefined in a subclass
>would be better in this case. There are already with different kinds
>of inheritance/visibility constraints for methods in some OOPLs, and 
>this one sounds neither far-fetched nor difficult to implement. 
>Further, it avoids the need for "coding discipline" that is the cause
>of many program errors.
>
>hal.

One major reason that testing inherited classes becomes complex is that
classes often have member functions and variables that cooperate; these
members must therefore be overridden in groups (or, if only a single
member of the group is overridden, the programmer must very carefully
ensure that the overriding function fits properly with the other members
of the group).

So, one approach would be to allow the programmer to specify groups of
member functions/variable.  The compiler could then give errors is
some, but not all, members of a group were overridden.  If the programmer
``knows what he is doing'', he can give the equivalent of a cast:

	class  foo : public parent_of_foo

		. . .

		inline int 	bar() { parent_of_foo::bar(); }

		. . .

		};

by explicitly inheriting the parent's behavior.

This approach of course requires additions to the languages in order to
specify the member groups.  However, it is a good fit to the major problem
and adds absolutely no runtime overhead (at least for languages that allow
inlining).
				Thanx, Paul