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

[stt@houdini.camb.inmet.com (Tucker Taft)]

Neil Wilson (nobody@nobody.com) wrote:

: Tucker Taft <stt@houdini.camb.inmet.com> wrote in article
: <EFLp4n.HJC.0.-s@inmet.camb.inmet.com>...
: > In my experience, separating the spec and body physically is
: > extremely advantageous, and the need to have redundancy between
: > the spec and body is an important feature in a multi-person
: > project, not an "inconvenience."  In Ada (and to some extent in C/C++

: Then do it. This is what fully deferred (or even partially deferred)
: classes do in Eiffel. You can even lock down the specification by providing
: only the Precompiled version to your implementors (or more simply lock out
: the deferred class file using file permissions).

One can always argue both sides of an issue like this.  

   1) Our language forces you to separate spec and body, and
      that is good.

   2) Our language allows you to separate spec and body, but
      doesn't force you to, so that is good.

Perhaps a more relevant question is what style "real" programmers
adopt when they use the language, and how this affects the
productivity, maintainability, readability, etc., of code
built in that language.

Note that the Eiffel folks argue exactly the opposite when they
talk about "purity" of OO languages, saying that Eiffel *forces*
you to put everything in a class, and that is good, whereas the
Ada folks say that Ada *allows* you to only use tagged types,
but doesn't force you to, so that is good.

Similarly, Eiffel forces you to only have exception handlers
at the top-level of an operation (which never seemed "good"
to me, but perhaps because I don't understand the full argument
in favor of this requirement), whereas Ada allows you to place
exception handlers as locally or globally as appropriate.

In general, language designers have to choose carefully between
where they "force" something on the programmer, and where they
simply support something.  Furthermore, when more than one approach
is supported, they have to choose whether one is made significantly
easier or more convenient than the other.  This is because the 
rules of the language have a subtle effect on the style adopted by 
the programmers.  It is certainly not zero effect, but it of course 
is not overwhelming, in that design approaches, past history, etc., 
all have an effect as well.

However, as far as separation of spec and body, I believe many
people who have used Ada over the past 15 years believe that this
separation "enforced" by Ada was perhaps its most fundamental
contribution to programming style.  Given that belief, it is very 
surprising (at least to me) to see some languages moving away from this
separation, and only "allowing" it (and sometimes requiring you to
work a bit harder and restructure a bit to do it).  

It is possible that the time for "forcing" this separation is past, but 
based on my recent use of Java in a multi-person project, I don't
think so.  The Java "interface" type and "abstract" classes are nice, 
but the fact that spec and body are merged in most Java classes,
even given tools like "javap" and "javadoc" to extract the interface, doesn't
substitute for separate spec and body.  

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.  

As an example, look at the "javadoc" produced for the Java 
standard API.  It gives you the facts, but almost nothing more.  
I suspect that if someone had been "forced" to write a 
separate spec for each of these classes, there would be something 
more "specification"-ish there (i.e. what the routines are 
supposed to do, in words).

: Neil Wilson (neil at aldur dot demon dot co dot uk)
: Aldur Systems Ltd, UK 

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA