Re: Building blocks (Was: Design By Contract)

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <01bcc7f6$638b7f60$108142c1@Yeif-1.eiffel.fi> "Veli-Pekka Nousiainen" <vp.nousiainen@remove_this_eiffel.fi> 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...