paj@mrcu (Paul Johnson) (02/28/91)
In article <27C6E8FC.2A70@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to cox@stpstn.UUCP (Brad Cox): >>Assertions are checked by the application's running image, not by the >>compiler. > >Of course. What I meant was, the programmer writes the condition >once, and the compiler inserts the code _where it is needed_, thus >saving grunt work. In particular, when one member function calls >another, it should be possible to delay any class consistency checking >until the outermost member function returns. Yup, and I think Eiffel does precisely this with class invarients. There is a theoretical reason as well as a practical reason: the inner function might be called with the class in an inconsistent state (i.e. invarients violated), or it might exit with an inconsistent state. This is not incorrect, since the client never sees this state. It only sees the state when the outer function exits. Hence as long as the outer function tidys the state up before exiting, there is no problem. This makes the programmer's job easier, since invarients no longer get in the way inside methods. Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@gec-mrc.co.uk | Fax: +44 245 75244