Re: Another important feature of Ada

[James Rogers <jimmaureenrogers@worldnet.att.net>]

"pete@nospam" wrote:
> 
> In article <PM0003765BB967CEAE@Dogen.ne.mediaone.net>, Ed says...
> 
> >
> >I agree with your point about the value of being able to compile against
> >unimplemented specs - it's always been one of my favorite aspects of
> >Ada.  But the same effect can be achieved otherwise.
> 
> not sure that compiling against unimplemented specs is that important.
> after all, you are just checking compiler syntax errors, and checking
> against any mismatched types. And you can do that in almost any
> other language. In Java for example using interfaces, and in C++ using
> pure virtual functions.

Java's interfaces are not a good example of a tool for separating 
interface from implementation because they are a special case for the
language.

It is impossible to define a Java interface such that the interface
defines all the public, default, and protected members (data and
methods)
defined in every class implementing that interface. Java classes can
inherit from exactly one class, either one explicitly declared with an
"extends" clause, or implicitly extending the Object class. At the same
time
a Java class may implement any number of interfaces. The term any number
maps pretty closely to the Ada Natural subtype.

Given that a class does not need to implement any interface, how can 
interfaces be a solution to the complete separation of interface and
implementation. Given that any class implementing an interface extends 
some other class, and may implement several interfaces, how can a Java 
interface be a solution to this problem?  It cannot.

Pure virtual functions are similar to Ada abstract subprograms. 
This is not the technique commonly used in C++ to separate interface
from implementation. The commonly used technique is the preprocessor.
The interface is commonly defined in the C++ header files, while the
implementation is defined in the C++ source files (.cpp or .C files).

The problem with using C++ header files is that the C++ language has
no restriction upon the contents of a header file. It is possible to
mix interface and implementation in a header file. Only programmer
discipline can prevent such a mixing.

> And in practice, it is only after running the program against the
> actual implementation that one finds for sure if the interface is
> the right one, also many times the interface is changed as development
> goes on.
> 

This of course reveals a process problem in several development
projects. The reason for changing interfaces is most often because 
insufficient analysis and design work was done before beginning 
implementation. The only time I have seen it necessary to change the
interface definitions has been when new requirements are levied on the
project after analysis and design is complete. This, again, is a
process problem. The separation of interface and implementation is
still useful in this case as it allows the design team to clearly
identify the current design problems and develop design alternatives.
Many times the interfaces do not need to be changed. Instead, some new
packages may be needed.

Note that performance issues have no impact upon the separtation of
interface and implementation since they are handled purely in the
implementation.

Jim Rogers
Colorado Springs, Colorado