Re: Design by Contract

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

Joerg Rodemann wrote:
> And exactly for that reason I would like to join the opinion that source
> seperation of specification and implementation is very useful as well.
> As far as I can tell this is a feature that Eiffel seems to be missing, as
> many other language. E. g. I rather liked Oberon for quite a while for its
> clean and simple concept. But the merging of definition and module files (as
> spec and implementation are called there) I found somewhat annoying. Surely
> I could see some benefits of this 'new' mechanism if Oberon is used within
> that graphical Oberon System. But I used an implementation of Oberon
> developped at the University of Ulm that simply sat on top of a Unix system.
> I thinks this mixin of spec and body would have messed up things a lot.
> 
> My experience with C++ and C supports this believe as well (note: this is
> just MY experience.) for people often do not care about this seperation.
> the craziest thing IMO is the inlining of methods within the class header
> in C++. If the code is not very well structured you can spend hours and days
> about just searching for the specifications. (And the debugger won't be of
> much help either... *sigh*)
> 
> As I see it a separation of spec and body is VERY useful and indeed some
> kind of contract as well. If it has to be counted among the constructs for
> DBC depends of this term's actual definition...

There are different ways of approaching the separation. I suspect the 
majority of people agree that separation is a good thing, but there are
more
than one way of achieving the aim. Approach one is the C++ way, separate
files.
The problem here is keeping them in line, consistent names etc. The
other approach
is to have one file, but have the ability to view the files in different
ways.
Extract the spcification, view everything. I believe the second way to
be the
better way as it is simpler, and you use the machine for something it is
good at
doing.

The drawbacks are if you want to publish a specification that won't
compile.
Why is my immediate response.

You need a means to publish specifications for libraries where you only
release
the compiled code, thereby hiding the implementation. 

-- 

Nick