Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Greg <gmc333NOgmSPAM@my-deja.com.invalid>]

"Howard W. LUDWIG" <howard.w.ludwig@lmco.com> wrote:
[snip]
>
>How are the "require" and "ensure" blocks handled--as
>executable code at run-time, as compiler-checking, or
>simply as comments to support humanoid review or automated
>checking by tools other than the Eiffel compiler?

AFAIK no Eiffel compiler can check require/ensure code at run-
time. Indeed, many of the assertions simply can't be computed
until runtime.

Compiler options can be used to toggle sets of assertions. ISE's
ACE (their makefile language) takes this control down to the
class level. So developers have a degree of control over how
much overhead the assertions add.

The burden of executing 'require' clauses need not be placed on
the callee. In examining the interface to a class, the compiler
has all the information needed to place that burden in the
caller's code. It simply inline's the require clauses before the
feature call. This is one reason that any features referenced by
a require clause have to be public.

For example, in the STRING class the index method (in
SmallEiffel) is declared as:

   item (index: INTEGER): CHARACTER
      --  Character at position index.
      require
         valid_index(index)

Here valid_index is a public feature. When a client of string
executes:
    c := str.item (n)
the compiler may translate this into (pseudo-C code):
    assert (str.valid_index(n))  // inlined require clause
    c := str.item (n)            // actual execution

So in principle one can deliver an Eiffel library as interface
definitions and optimized code, and still get the benefits of
DbC.

(Ensure clauses are a different matter. They can access private
data and have to be compiled into the service object. Ideally,
if one ships an optimized binary library, one's already done a
lot of work to make sure that all the ensure clauses are
redundant.)

The require/ensure clauses are also a great humanoid review tool.
See for example the ongoing ELKS 2000 standardization process,
http://www.egroups.com/group/eiffel-nice-library
Practically all of the discussion focuses on feature names and
the require/ensure clauses supported by the features. Rarely are
implementation details discussed, and comments are used
sparingly. (Try THAT in C++ why doncha!)

[snip]



-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com