Re: contractual programming

[Jeff Dalton <jeff@aiai.edinburgh.ac.uk>]

Scott Fahlman writes:

> The next step would be to build a table associating a "contract" predicate
> with each class.  A call to (CHECK-CONTRACT <object>) would retrieve the
> contract associated with that class (if any), then proceed as for ASSERT.
> Again, this is trivial to write as a portable library.
> 
> The final step would be to modify all the setters to run check-contract
> after they do their thing. 

The Eiffel approach is to have a condition (and "invariant") that
a method can assume is true when it starts and that it must make
sure is true when it finishes (or invokes another method? -- I'd
have to look up the details).  But it doesn't have to be true after
every modification to the object.  I think there must be a number
of cases where an object has to be in an invalid state temporarily.
For instance, maybe two changes have to be made before it's valid
again.

So I suspect that checking after every change might make life
more difficult than it ought to be.  However, I also suspect that
in Eiffel changing the value of a slot (or are they instance
variables?) does not involve calling a method.  This would make
it easier to have a rule about what methods have to preserve
that doesn't also apply to all modification performed within
a method invocation.  If all modifications are done via methods,
it's harder to draw such a neat distinction.

-- jeff