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,2c6139ce13be9980
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,3d3f20d31be1c33a
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,2c6139ce13be9980
X-Google-Attributes: gidf43e6,public
From: Joachim Durchholz <joachim.durchholz@munich.netsurf.de>
Subject: Re: Interface/Implementation (was Re: Design by Contract)
Date: 1997/09/06
Message-ID: <3411BB3C.E6CFC8A@munich.netsurf.de>#1/1
X-Deja-AN: 270343817
References: <340F3801.47E5@pseserv3.fw.hac.com> <EG0upp.Irq@syd.csa.com.au>
 <3410309E.6A32@pseserv3.fw.hac.com>
X-Priority: 3 (Normal)
Newsgroups: comp.software-eng,comp.lang.ada,comp.lang.eiffel
Date: 1997-09-06T00:00:00+00:00
List-Id: <comp.lang.ada>



W. Wesley Groleau x4923 wrote:
> If you are looking for a particular operation, why are you scrolling
> through?

Well, personally I don't scroll through too often, but this is often
useful to get a first impression on what a class does. A good ordering
can be valuable.

> If you are trying to understand an operation's
> implementation, you look at it, and if it calls another, you may
> choose to find that.

Finding the implementation interrupts the reading process. These
interruptions are barely tolerable if just clicking the identifier in
question brings me to its definition (or implementation), but explicitly
calling up a Find dialog breaks my concentration.

> There is a difference between the usefulness of the "spec" (which
> I've been led to believe in Eiffel _includes_ certain essential
> comments),

There might be a misunderstanding at work here. Wether these comments
are essential or not depends on your point of view.
At the language level, these comments have the usual comment semantics,
i.e. removing them doesn't change anything.
However, they are useful because they go into the text extracted by the
short and short-flat tools; because of this you can have all sort of
documentation here. This includes:
- Assertions that the language cannot express because they are informal,
e.g. "Result is a nicely formatted report template".
- Assertions that we don't want the run-time system to check even if
assertion checking is on, because they are too time-consuming to check,
e.g. "Result is acyclic" where Result may be a graph with several
million edges.
- Comments on assertions, e.g. "This precondition should go away in
future versions".

> Put another way,
> is a short (or short flat) adequate for me to code a client if
> the coder did not put his comments in the right place or format?

It's just the right place (no formatting conventions *inside* Eiffel
comments). And it is very difficult to get the place wrong.

A typical Eiffel routine looks as follows:

  feature
    <routine name> (<parameter list>) is
    require
      <put your preconditions here>
    ensure
      <put your postconditions here>
    do
      <routine body>
    end


-- 
Please don't send unsolicited ads.