Aaron Harsh (ajh@rtk.com) wrote: : I noticed in the Eiffel FAQ that "Sather does not support Design by : Contract." Sather appears to support pre/post-conditions, and class : invariants.
: What is the rationale behind the statement in the FAQ?
Two points:

1. this entry is *old*, it may have appeared before Sather started to support pre/postconditions/invariants

2. Substitution in Sather is achieved by subtyping from abstract types void of any implementation. Unfortunately you cannot annotate these abstract types with pre/post/invariants which would be very useful. For example abstract framework classes (which would be Sather 'types') could be annotated with the appropriate semantics that have to be preserved when implementing a descendant of such a class. Therefore part of the rationale behind Eiffel's strengthening of postconditions / weakening of preconditions / ... simply does not apply to Sather and gives a litte truth to the statement. ( To be fair, it's quite hard to find a suitable semantics for DBC in the Sather system. )

-- Matthias

From: wicklund@intellistor.com (Tom Wicklund) Newsgroups: comp.lang.sather Subject: Re: Design by Contract -- Eiffel v. Sather Date: 23 Feb 1998 22:32:00 GMT Organization: Fujitsu Computer Products of America, Intellistor R&D In <888035961.638484@ridge.spiritone.com> "Aaron Harsh" <ajh@rtk.com> writes:

>I noticed in the Eiffel FAQ that "Sather does not support Design by >Contract." Sather appears to support pre/post-conditions, and class >invariants.

>What is the rationale behind the statement in the FAQ?

Probably because Sather is not as strict in its implementation of Design by Contract.

Sather doesn't handle pre/post conditions and inheritance since it uses a different inheritance model than Eiffel. It also doesn't support assertions in loops directly (though it's simple to write "variant!" and "invariant!" iterators). I'm sure there are other differences.

I think it more honest to say that Sather provides the tools required for Design by Contract (in particular, automatically performing postcondition and invariant checks, which are hard to simulate in other languages).

Whether one is actually using Design by Contract is then more a matter of programmer intent than language. One can write good or bad code in any language.

ablazej@gnu.org