Re: OO, C++, and something much better!

[Richard Riehle <rriehle@nunic.nu.edu>]

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