Path: utzoo!attcan!uunet!mailrus!uwm.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!render
From: render@m.cs.uiuc.edu (Hal Render)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <1990May30.204110.22011@ux1.cso.uiuc.edu>
Date: 30 May 90 20:41:10 GMT
References: <1990May20.154035.15064@axion.bt.co.uk| <54783@microsoft.UUCP> <5121@stpstn.UUCP> <54917@microsoft.UUCP> <480@tetrauk.UUCP>
Sender: usenet@ux1.cso.uiuc.edu (News)
Reply-To: render@m.cs.uiuc.edu.UUCP (Hal Render)
Organization: University of Illinois, Dept. of Comp. Science, Urbana
Lines: 21

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.