[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: contractual programming
- To: Jeff Dalton <jeff@AIAI.EDINBURGH.AC.UK>
- Subject: Re: contractual programming
- From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU
- Date: Wed, 21 Oct 92 15:52:40 -0400
- Cc: info-dylan@CAMBRIDGE.APPLE.COM
- In-reply-to: Your message of Wed, 21 Oct 92 18:55:38 +0000. <firstname.lastname@example.org>
> 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
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 E. Fahlman Internet: email@example.com
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213