From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,9a0ff0bffdf63657
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
X-Google-Thread: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
From: jtc@dimensional.com (Jim Cochrane)
Subject: Re: Software landmines (loops)
Date: 1998/09/02
Message-ID: <6skh4n$491@flatland.dimensional.com>#1/1
X-Deja-AN: 387281953
References: <slrn6sopmg.4fg.jdege@jdege.visi.com>
 <LpVjTBAegG71EwXH@radm.demon.co.uk> <6silt4$gb0@flatland.dimensional.com>
 <9qnQhDAAvZ71EwAx@radm.demon.co.uk>
Organization: Dimensional Communications
NNTP-Posting-Date: Wed, 02 Sep 1998 16:34:13 MDT
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-09-02T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <9qnQhDAAvZ71EwAx@radm.demon.co.uk>,
Richard Melvin  <rmelvin@radm.demon.co.uk> wrote:
>In article <6silt4$gb0@flatland.dimensional.com>, Jim Cochrane
><jtc@dimensional.com> writes
>>
>>It appears that this routine has an implied pre-condition:
>>l.size() == r.size()
>>
>snip..
>>
>>I think, more appropriately, it argues for the "Document routine
>>pre/post-conditions (as well as use assertions as documentation of
>>program state, where appropriate)" camp.
>
>I hardly think so, given that this was a comparison operator for a stack
>- a stack, pretty much by definition, is variable-length (perhaps with a
>fixed maximum length, but that's not relevant).
>
>Just throwing in extra preconditions to cover bugs in the implementation
>is not my interpretation of design-by-contract.

You are correct.  My premise was a bit off.  A better one would be:
Before implementing a routine, it is necessary to determine what the
routine must accomplish.  A very effective method of doing this is to
document the specification for the routine in the form of pre- and
post-conditions.  Once this is done, the routine can be coded such that it
meets the post-condition based on the pre-condition.

In the quoted example, documenting the pre-condition would have helped to
uncover the fact that containers of different sizes would need to be dealt
with.  It would become obvious that a pre-condition of l.size = r.size
would not be appropriate and thus that the negation of this condition would
need to be dealt with in the implementation.

>
>Otherwise I can revolutionise the world of fast sort algorithms:
>
>void 
>sortInLinearTime(Vector & v)
>{
>        PRE (v.length() < 2);
>        return;
>}
>
>(assuming PRE is counted as an externally-documented precondition, not
>an assertion).
>-- 
>Richard Melvin


-- 
Jim Cochrane
jtc@dimensional.com