[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: contractual programming
- To: Scot Dyer <email@example.com>
- Subject: Re: contractual programming
- From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU
- Date: Tue, 20 Oct 92 14:07:17 -0400
- Cc: info-dylan@CAMBRIDGE.APPLE.COM
- In-reply-to: Your message of Mon, 19 Oct 92 09:34:27 -0800. <9210191634.AA00726@eagle.sharebase.com>
For those of you who just tuned in, contractual programming is the attaching
of some expression to a class or a method to be used as a contract. If the
expression ever evaluates to #false, the contract has been violated and an
error is signalled.
Well, something like the Common Lisp ASSERT (test some arbitrary predicate
and signal a value if it is false) would do part of what you want. It
might want to be part of the base language, just to encourage people to use
it, but it would be trivial to add it as a library. The only problem is
that you have to sprinkle these around your program in specific places.
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. I'm not sure if this could be written somehow
as a mix-in method on SET! and INITIALIZE -- it's a bit unclear since the
former is a syntax-form and the latter is perhaps being revised. But I'm
sure there's some way to get this effect. I certainly wouldn't want this
to be the default, however. Contracts have their charm, but I don't want
to slow down *all* modifications to check them.
Scott E. Fahlman Internet: firstname.lastname@example.org
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213