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

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Don says

<<IMHO, this is how it should be. One of the annoying things I find with the
ability to order operations differently in Ada spec and body is that you
see them in a certain order in the spec and may have trouble finding them
in the body because they've been re-ordered, often due to compilation
dependencies. IMO, there's no excuse for imposing dependency-related ordering
in an age of multi-pass compilation.

Does the Ada95 standard impose dependency-related ordering?>>

No, and neither does the Ada 83 standard in this context, so your comment
about finding this annoying is simply confused.

We are talking about the order in the body of entities declared in the spec.
Clearly these have all been previously declared, so the order of subprogram
bodies in the body of the package is completely free, I have no idea what
you are talking about.

If you see a different ordering in the spec than in the body, it is not
because of "compilation dependencies", it is because the programmer thinks
this is a good idea. Yes, I know, language designers are partially in the
business of telling the programmer that they know better than the programmer
does and imposing restrictions, but this one seems inappropriate.

What I often find quite appropriate in Ada is to group the specs in a logical
order in the package spec, since this is often browsed to get an idea of the
facilities offered by a package by humans, and an appropriate logical order
can help this browsing.

On the other hand, you never need to browse the body as a client of the 
package, so the logical ordering requirement for such browsing does not
apply. The two files are viewed VERY differently in an Ada environment,
not only will different people touch them, but different people will look
at them, and the client of a package should almost never be looking inside
the body -- if they need to, it shows something is wrong with the spec.

Incidentally the separate files aid this goal. An Ada programmer expects
to find everything they need in one file, and is definitely annoyed, and
knows that there is a bug, if they have to go and look at the body. If you
put things in one file, even a single file with different views, it is far
too easy for programmers to get in the habit of looking at this file without
going though the restricted interface view, and thus not to be sensitive
enough to enforcing the separation. Yes, tools could make this harder, but
in practice, not everyone is using such tools, and it is all too easy for
a client to easily browse the implementation.

Going back to the ordering issue, in the body, I usually prefer to arrange
the subprograms in alphabetical order, because this is easier for reference
purposes for the implementor who needs to go to a particular body to debug
or otherwise fiddle around.

That's the *crucial* difference between the spec and the body, the spec gets
browsed as a whole, the body never does. I quite see how Eiffel programmes,
or other programmers not used to this strong separation would not see the
benefit of being able to organize the two objects differently, you do not
miss what you do not have.

One of the most widespread weaknesses, even among experienced professional
programmers, is the inability to comprehend the importance of separating
specification from implementation. Note tha the entire "comments are useless,
my code is self documenting" view is fundamentally at odds with this basic
requirement of separation.

Yes, you can separate effectively in any language if you work hard enough
(the equivalent of a separate spec can be created entirely by commenting
even in a language like COBOL or BASIC with absoslutely NO avbstraction
capability of this sort), but in practice, a language like Ada where this
separation is very strong will encourage more programmers to understand
the importance of the separation. In the Ada world, absolutely everyone
understands that you should be able to use a package only looking at its
spec and not its body, and the fact that the spec can be handled separatly
as a coherent compilable entity is one of the most important aspects of
Ada, since it leads even inexperienced not very competent programmers
to fully grasp the importance of the separation of spec and body.

<<dependencies. IMO, there's no excuse for imposing dependency-related ordering
in an age of multi-pass compilation.>>

Though this technical point is completely irrelevant to the main thread
of discussoin here, if you are saying that you should be able to use entities
before they are declared. I strongly disagree. Sure my compiler can make
multiple passes through a source document, but as a human reading the
document, I prefer not to. There is a reason why we arrange text books,
and other materials not to have forward references (such as mentioning
a character in a novel before introducing them). Programs benefit in the
same way from a basically linear approach, in which overall understanding
can be obtaineed in a single linear pass.

But as I noted, this point is totally irrelevant to the discussion, since
of course the spec appears "before" the body, so there are no ordering
relationships imposed on the entities in the body that correspond to those
in the spec in any case.