[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: contractual programming
- To: email@example.com
- Subject: Re: contractual programming
- From: Jeff Dalton <firstname.lastname@example.org>
- Date: Wed, 21 Oct 92 18:55:38 BST
- Cc: email@example.com
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
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.