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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: Richard Riehle Subject: Re: OO, C++, and something much better! Date: 1997/01/27 Message-ID: #1/1 X-Deja-AN: 212684502 references: <32CCE4ED.6A21@online.no> <5ajo99$khu@panix.com> <32ce7009.280817694@news.zip.com.au> <32D0CA27.44C2@ghgcorp.com> <32D245D5.2C0@ghgcorp.com> <32D2E6C8.13728473@eiffel.com> <32D536C6.64880EEB@eiffel.com> content-type: TEXT/PLAIN; charset=US-ASCII organization: National University, San Diego mime-version: 1.0 reply-to: Richard Riehle newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-01-27T00:00:00+00:00 List-Id: On Thu, 9 Jan 1997, Bertrand Meyer wrote: > To the four properties listed in my original I should also add two > just as essential requirements: true multiple inheritance, for combining > different abstractions (and with the right mechanisms to avoid any > ambiguity or conflict); and, most importantly, Design by Contract > and the rules on how assertions combine with inheritance. As someone > remarked, it is really impossible to understand inheritance without > understanding Design by Contract. Bertrand, I understand that the notion of "design by contract" was probably your original contribution to the literature, and I also realize that your concept of it is inextricably linked to the Eiffel model for assertions. However, I would like to suggest another view of the same idea. Assertions, as I understand them are predominately a run-time check on the software entities. If I may oversimply, Preconditions "require" that certain propositions are true for a feature to begin executing, Postconditions "ensure" the other propositions are true upon leaving a routine, and Invariants guarantee that certain entities remain intact during execution. While this description does seem to oversimplify the Eiffel design of assertions, I hope it will not offend you. The Eiffel assertion model contains all of the elements of an Ada type, though an Ada data type does not contain all the elements of an Eiffel assertion. When I say, type T is ... ; I am saying for T that there is a set of assertions which are post-, pre-, and invariant. These assertions, implied to be sure, are also checked at run-time. I am saying by the declaration for T, that there is a minimum value for T, a maximum value, and any routine that uses T must not let it stray from that range. Also, in Ada 95, I can check the validity of that value at any time using the expression, if T1'Valid then ... end if; where T1 is a value of type T. My question is, can one write an invalid assertion in Eiffel? That is, can the expression for an assertion be some complex that it contains the very kind of error that we are trying to avoid with procedural code? If I define an assertion, require some complex mathematical expression ensure another complex expression is there some mechnism inherent in Eiffel that can evaluate my assertions for correctness? The Ada model for pre-, post- and invariant conditions is, to be sure, more conservative and less sophisticated than designed into Eiffel. But that very conservatism contributes to the simplicity of the process of creating specifications. Although Ada software developers do not customarily use the expression, "design by contract," that is exactly what they are doing whenever they design their own data types and specify the acceptable ranges and boundaries acceptable for those types. As for the assertion mechanism, itself, there is probably no reason why a compiler publisher could not add to an implementation three pragmas, pragma Precondition ( expression ) pragma Postcondition ( expression ) pragma Invariant ( expression ) but in so doing we must ask whether the addition of such pragmas would really make the resulting program more reliable than it was using the more conservative model of simple type definition. Bertrand, on a personal note, I am glad to see you engaged in this dialogue. We need more of this level of discussion here. Thanks. Richard