Re: Eiffel and Java + Ada dispatching

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

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