[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: contractual programming
- To: info-dylan@cambridge.apple.com, jeff@aiai.edinburgh.ac.uk
- Subject: Re: contractual programming
- From: dyer@eagle.sharebase.com (Scot Dyer)
- Date: Tue, 20 Oct 92 09:56:38 PDT
/// 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.
///
/// This sounds similar to the "class invariants" (is that right?)
/// in Eiffel.
I don't know enough about Eiffel to say, I'm afraid. The idea is to provide
a conveniant space in class/method definitions for run-time error checking,
since this can be awkward without them, leading programmers to fly by the seat
of their pants during development... One hopes that by giving them a suitably
painless avenue towards value-checking that they will develop robust
applications with a good amount of error checking.
Is this what "class invariants" buy one in Eiffel?
-- Scot