Re: contractual programming

[Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU]

    > 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.
    
OK, I can see that checking the object's contract after each modification
could well be the wrong thing.  There are places in the code where you want
to be sure that the contract is valid, and strecthes where it can't be.

Given this, I don't think it's obvious that method exit is always the
right place to check.  One might call several sub-methods that mess up an
object before some surrounding method fixes it again.

All of which brings me back to the view that the user should just insert
ASSERT or CHECK-CONTRACT calls where he thinks they belong.

-- Scott

===========================================================================
Scott E. Fahlman			Internet: sef+@cs.cmu.edu
Senior Research Scientist		Phone:    412 268-2575
School of Computer Science              Fax:      412 681-5739
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213