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/03 Message-ID: #1/1 X-Deja-AN: 277669750 References: <5v34m5$pl9$1@trumpet.uni-mannheim.de> <34215E3D.77AE@gsfc.nasa.gov> <3421E190.49CC@chimu.com> <3423BE13.9C3852A4@munich.netsurf.de> <01bcc7f6$638b7f60$108142c1@Yeif-1.eiffel.fi> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-10-03T00:00:00+00:00 List-Id: In article <01bcc7f6$638b7f60$108142c1@Yeif-1.eiffel.fi> "Veli-Pekka Nousiainen" writes: > It is clear to me that postconditioning is missing in all other languages > exept Eiffel (Sather???). If all you need is comments, then my old > hex-assembler for an 8-bit processor is all O-O with DbC, I just comment... Actually Ada does have a quite well defined concept of pre- and post- conditions for subprograms. However, they are implicit rather than defined as part of the syntax. This guarentees that the conditions are always true, but it makes it hard to add complex postconditions. for example: subtype NNFloat is range 0..Float'Last; function Square_Root(F: in NNFloat) return NNFloat; guarentees that if no exception is raised that F is non-negative (pre-condition) and the return value is also non-negative. It also promises that all task depending on Square_Root have terminated, that all Controlled objects within Square_Root have been finalized, etc. Note that this second group of post-conditions is true whether or not an exception is raised, unless, of course, the finalization action raises an exception not handled locally--very bad form. However, defining types and subtypes is Ada is a much more awkward way of checking different postconditions than is possible in Eiffel. And also, the definitions of the subtypes and the body of the subprogram are often distant from the declaration. Thus the habit/practice of documenting the actual pre and post conditions in comments when not obvious from the declaration. 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, rather than associating the conditions with the last subprogram called. However in both Ada and Eiffel, the normal case is that the post-conditions for operations of a class or type are all identical. In that case, it matters little which approach is used. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...