🚀 go-pugleaf

Scott Wheeler (scottw@bmtech.demon.co.uk) wrote:
: In Article <4an3i4$43f@news.irisa.fr> Jean-Marc Jezequel writes:
: >I basically agree with you but IMHO, the most important "bells and 
: >whistles" to the Design by Contract idea in Eiffel is that assertions 
: >are inherited by subclasses. That way you can constrain the 
: >implementor of an abstract (i.e. deferred, pure virtual) method to 
: >meet the requirements specified in its contract.

: Agreed. BTW, looking back on my posting, I regret to say I was 
: indulging in my favourite vice of didacticising. I used to be a 
: teacher and I can't quite get out of the habit of explaining things 
: interminably.

: >This is where I find the assert.h package too much limited in C and 
: >C++. If someone has an idea on how to emulate this mechanism in C++, 
: >I'm a taker.

: The problem comes in doing it efficiently and cleanly. I'd approach it 
: by writing a pre-processor to generate C++ code from an extended 
: version of the language.

: <example deleted>......

That missed what I think is the most crucial (and yet simple) part of
Eiffel-style conditions.

Namely that a violated precondition points out a mistake in the CALLER.

Therefore, precondition faults should do something obviously *different*
from generalized assertion violations or invariant or postcondition
faults.   If some random "assert" goes off, who's fault is that?  With
C or C++ and the typical use of "assert" it's hard to say. Was it bad input
data?  Was it a mistake in the code?  Was it because somebody else didn't
implement the full functionality?  Or what? 

A good point of of 'design by contract' is that if you think about making
the contracts right, you should be able to figure out 'whose fault was the
mistake?' That way you'll be more likely to eliminate the truly erroneous code,
instead of mistakenly adding an ameliorating superficial patch. 

cheers
Matt