Good Contract programming idiom?

[retard]

Wed, 03 Mar 2010 14:09:59 -0800, Brad Roberts wrote:

> On Wed, 3 Mar 2010, Norbert Nemec wrote:
> 
>> The edited Wikipedia text for D is so far correct, even though the
>> whole page is not quite as precise as it could be. The theoretical
>> basis and the practical application are somewhat mixed. Fixing that,
>> however, would be a major task.
>> 
>> I think the fundamental distinction between three concepts is essential
>> in understanding the issue:
>> 
>> * exceptions - handling of run-time conditions caused by user, file,
>> network or any other kind of input. Hitting an exception is not a bug
>> but a regular function of the code.
>> 
>> * contracts - well designed parts of interfaces. Best understood
>> literally as "contract", defining who is responsible for a bug. The
>> possibility to check a contract at runtime is actually a secondary
>> function.
>> 
>> * assertions - best understood as "comments" that can be checked by the
>> compiler. Sprinkle them freely wherever you find some non-trivial
>> relation between variables of the code.
>> 
>> I guess this whole issue simply is something that has to be discussed
>> more frequently to make people aware of it.
>> 
>> Greetings,
>> Norbert
> 
> There's an important point that's been left out of this conversation so
> far (unless I missed it):
> 
> Asserts in the body of a method have no impact on overridden
> implementations in subclasses, but in/out contracts do.  So there's a
> distinct value in using in/out for non-final methods.

The fact is also mentioned here:

http://en.wikipedia.org/wiki/Design_by_contract

"Subclasses in an inheritance hierarchy are allowed to weaken 
preconditions (but not strengthen them) and strengthen postconditions and 
invariants (but not weaken them). These rules approximate behavioral 
subtyping."