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,f66d11aeda114c52
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,f66d11aeda114c52
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Building blocks (Was: Design By Contract)
Date: 1997/10/14
Message-ID: <EACHUS.97Oct14170105@spectre.mitre.org>#1/1
X-Deja-AN: 280514431
References: <5v34m5$pl9$1@trumpet.uni-mannheim.de>
 <wihnDCAGPDI0IwlD@treetop.demon.co.uk> <34215E3D.77AE@gsfc.nasa.gov>
 <3421E190.49CC@chimu.com> <EGrz21.GoG@world.std.com>
 <3423BE13.9C3852A4@munich.netsurf.de>
 <mheaney-ya023680002209971930310001@news.ni.net>
 <01bcc7f6$638b7f60$108142c1@Yeif-1.eiffel.fi>
 <EACHUS.97Oct3164342@spectre.mitre.org>
 <J87JkUA6zdN0Iwrm@treetop.demon.co.uk>
Distribution: world
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-10-14T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <J87JkUA6zdN0Iwrm@treetop.demon.co.uk> Paul Johnson <Paul@treetop.demon.co.uk> writes:

  > The problem is that it doesn't let you say things like

  >    item: T is
  >	 require
  >	    not empty

    Actually Ada does allow this type of restriction as well but only
for certain classes of types.

   (I said:)

   >   Which is better?  I prefer the Ada approach, where you can, with a
   >little bit of caution, always count on the value of the object meeting 
   >all of the rules for such objects,

   (Back to Paul:)

   > You can count on it for Eiffel as well: invariants state this kind of
   > thing.

   Not quite.  The difference is that in Eiffel, invariants are
checked at discrete points, while in Ada the corresponding checks
occur before each assignment, so that a valid object never becomes
invalid.

   Now, as such this is not a criticism of the Eiffel approach.  There
is a lot of code you couldn't write if some checks were done when
components of an object were modified.  With the Ada approach, you
have to do a whole record assignment if you change the discriminant of
a record, so there is the overhead of creating and copying the new
value, even if it is only slightly different from the old.

   As a result, you end up designing your objects differently for the
two different approaches.  I prefer the designs which match the Ada
idiom, where the structural effects of this are at a very low level.
But it is just that, a preference.  (And yes, I have had cases where
the "pure" Ada design worked just fine, but had horrible performance.
The fixes often include things like replacing an array of records with
an array of pointers to records, or vice-versa.  But the nice feature
is that you can make these low level performance changes AFTER
debugging your code.  You may be removing some of the lifeboats, but
at least they were there when you tested the package initially.)

   
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...