Re: Interface/Implementation (was Re: Design by Contract)

[Nick Leaton <nickle@calfp.co.uk>]

Matt Kennel (Remove 'NOSPAM' to reply) wrote:
> 
> On Thu, 28 Aug 1997 14:53:19 GMT, Tucker Taft
> :The hand-written Ada package spec (or even C header) remains a far
> :superior interface document for a given abstraction than is anything
> :I have seen extracted by a tool.  The result of extraction by a tool
> :typically ends up getting some but not all of the comments, and the
> :various operations are not presented in necessarily a helpful order,
> :or with any useful higher-level organization.
> :
> :Basically, the extraction tool tends to tell you what an abstraction
> :"is" or "does", rather than what it is supposed to do, and why.
> :When trying to decide whether a given implementation is correct,
> :without that separate human-written spec, it is much harder to evaluate.
> :One is simply stuck trying to evaluate internal consistency, rather
> :than consistency against a separate human-written spec.
> 
> I agree that these are important, but I don't see how Eiffel abstract
> classes are inadequate for this purpose.

The reason lies with how Eiffel handles comments and its support for
pre and post conditions and class invariants.

In Eiffel not all comments are equal. If you look at the syntax of the
language although all comments have the same appearance '--' and all
characters to the
end of the line, comments appear in the syntax. Comments appearing in
certain places in the code, for example, just after the class name are
documentation comments and appear in the 'short form'. (The spec). You
also have assertions that closely correspond to the spec, saying what
the feature will do for you if you satisfy the precondition. In other
words a lot of your spec ends up in you classes.

As to ordering, well you should be ordering your code, as you should be
ordering your spec.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.