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,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: Richard Riehle Subject: Re: Eiffel and Java + Ada dispatching Date: 1996/11/15 Message-ID: #1/1 X-Deja-AN: 196734156 references: <6KkYnJwk3RB@herold.franken.de> content-type: TEXT/PLAIN; charset=US-ASCII organization: National University, San Diego mime-version: 1.0 newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-15T00:00:00+00:00 List-Id: On 12 Nov 1996, Joachim Durchholz wrote: > This is the normal contract on parameter and result types. Eiffel > contracts also include arbitrary boolean expressions, extending the > contracting idea far into the area of program semantics. > Just as a parameter type makes clear what sorts of parameters are > required, the preconditions make clear under what circumstances the > routine may be called and expected to return a correct result. The Eiffel > postconditions list what the routine guarantees to the caller in turn. It is not a question of whether Ada includes a contract in its package specifications. The model for defining such a contract in Ada is a simple type definition with optional ranges and the set of operations for that type. In object-oriented programming, to implement inheritance with class attribute extension (Ada has always had inheritance with attribute extension), on uses tagged types for the contract. I am fond of both Eiffel and Ada. However, I sometimes wonder about the underlying reliability of assertions versus simple type definition. It seems to me that one can easily design an assertion that exceeds, in complexity, the wonderfully simple examples one sees published in Eiffel books. And as these assertions become more complex, are we increasing the risk associated with that assertion. I suspect that including assertions in Ada 95 would have made some practitioners happy. Would such a feature (no Eiffel pun intended) contribute to underlying reliability goals of Ada. Moreover, a fundamental notion in Ada is for the compiler to detect the maximum number of errors as close to the design specification as possible. Assertions are focused on run-time rather than comple-time. The structural differences between Ada and Eiffel are sometimes cited by advocates of both languages for their benefits. Eiffel enthusiasts sometimes claim the "module is type" model is superior. Though the case for this can be quite compelling, in software engineering practice the package model of Ada fares quite well. Ada's separation of specification from implementation contributes to a design that takes advantage of what Bertrand Meyer has called, "Linguistic Modular Units." In Ada this is possible because we can define package specifications that are readable by our customers, by the systems engineers, and throughout all phases of the project. Such specifications can be straightforward in describing the "what" with little need to examine the "how." I call this model of "Linguistic Modular Units" in Ada, a Project Level Linguistic Backplane. Whenver my clients have taken this approach, using Ada as the linguistic backplane for their entire project, they find it quite useful. I find it entirely too easy to include algorithmic details in the definition of an Eiffel class. Consequently, I believe the Ada separation of specification from body compensates for its lack of an explicit assertion model. Moreover, the very fact of a type definition, along with the rules for types, constitutes an implicit notion of precondition, postcondition, and invariant that is checked quite rigorously by the Ada run-time. Richard Riehle