Another important feature of Ada

Another important feature of Ada

[James Rogers]

I have been following a thread between comp.lang.eiffel and
comp.lang.c++.moderated. The thread is boiling down to a discussion of
the virtues and vices of separating interface from implementation.

The points being made against sepration of interface and implementation
focus on a concept that duplication of code is BAD, and separation
of interface and implementation requires some duplication of code.

The points being made in favor of separation of interface and
implementation are that separation more fully supports the needs of 
large scale software development teams.

C++ supports this separation by means of the #include syntax inherited
from C. Of course, the problem with the #include syntax is that it
does not enforce the separation of interface and implementation. As 
in many other features of C/C++, this is left up to the discipline of
the software developer.

It is interesting that Ada has been cited as being possibly the perfect
example of a language fully supporting and enfocing the separation of
interface and implementation through the use of Ada bodies and
specifications.

Eiffel programmers feel separation of interface and implemenation is
not beneficial because large Eiffel programs have been constructed
without this feature.

This is like saying that we do not need to have hammers in our
toolbox. Any sufficiently large wrench can be used as a hammer with
success. It is also possible that those same Eiffel programmers have
never actually tried to produce large scale software, but only know
of someone who has. This would naturally lead to the assumption that
no particular problems were encountered due to a lack of separation
of interface and implementation.

Jim Rogers
Colorado Springs, Colorado

Re: Another important feature of Ada

[Mark T]

> C++ supports this separation by means of the #include syntax inherited
> from C. Of course, the problem with the #include syntax is that it
> does not enforce the separation of interface and implementation. As
> in many other features of C/C++, this is left up to the discipline of
> the software developer.
>
> It is interesting that Ada has been cited as being possibly the
perfect
> example of a language fully supporting and enfocing the separation of
> interface and implementation through the use of Ada bodies and
> specifications.
>
    I do more C programming than Ada, but until I learned Ada I did not
fully appreciate "programming to an interface". I think it is one of the
best ways to get users of your modules to ignore the inner workings and
utilize the blackbox specification. When you have a 100,000 lines of
code everbody on the project can't be an expert on every LOC. The small
amount of subroutine name duplication doesn't seem to be much of problem
versus the benefit gained.

   On the other hand, the interface specification should fully point out
any limitations, etc, a "contract" needs to be fully defined for usage
of that module. (Sometimes programmers like to bury this info in the
implementation).



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Another important feature of Ada

[Tucker Taft]

I also believe strongly in the value of separating interface and implementation.

Whenever I discuss this issue, I generally fall back on the analogy of
a legal contract, where it would be frightening to have to ask the company working
for you to give you "today's contract," which they will extract from
the current work in progress.  

This is essentially the story in Java and Eiffel with classes, 
where there is no separate spec, but you can
extract the "contract" from the implementation.  Of course, Java has
"interfaces" and Eiffel has "deferred classes," but there is a lot of
code which is not just implementing one of these, and all of that
code has no physically separate "contract" defining what it does.

Not cool in my view.

From anecdotal experience, the fact that Ada has separate package specs
is very helpful in getting developers to focus on the notion of an
interface.  With Java, that seems to be getting lost again.

-Tucker Taft  stt@averstar.com

Re: Another important feature of Ada

[Laurent Guerby]

Tucker Taft <stt@averstar.com> writes:
> I also believe strongly in the value of separating interface and
> implementation.  [...] This is essentially the story in Java and
> Eiffel with classes, where there is no separate spec, but you can
> extract the "contract" from the implementation.  [...]

The Ada way is of course write the spec and have a tool build a
dummy implementation for it (C-c o under your favourite editor or
gnatstub with your favourite free compiler ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: Another important feature of Ada

[Ed Falis]

Well, I'm going to be a bit heretical here, having done a little Eiffel
programming and a lot of Ada programming.  DbC in conjunction with the
tool-enabled extraction of interfaces, and the use of deferred classes,
more than makes up for the lack of physical separation.  The "little"
Eiffel I did was several thousand lines of a GUI tool.  It worked rather
nicely.

In the end, it strikes me as a wash, since I can do more or less the
same in Ada as Eiffel DbC using asserts and (in the case of gnat, pragma
debug to provide inherited contracts and overrides).  The Eiffel DbC
capabilities take less work to accomplish the same end.  The Eiffel
ability to present only the interface in the IDE is less work than
separately writing specs and bodies.  And fully deferred classes handle
the pragmatic need for control of interfaces separate from
implementations by different stakeholders.  Both languages accomplish
similar goals, and it seems a matter of taste as to which to prefer.
These languages have more in common than most.

- Ed

Tucker Taft wrote:
> I also believe strongly in the value of separating interface and
> implementation.
>
> Whenever I discuss this issue, I generally fall back on the analogy of
> a legal contract, where it would be frightening to have to ask the
> company working
> for you to give you "today's contract," which they will extract from
> the current work in progress.
>
> This is essentially the story in Java and Eiffel with classes,
> where there is no separate spec, but you can
> extract the "contract" from the implementation.  Of course, Java has
> "interfaces" and Eiffel has "deferred classes," but there is a lot of
> code which is not just implementing one of these, and all of that
> code has no physically separate "contract" defining what it does.
>
> Not cool in my view.
>
> From anecdotal experience, the fact that Ada has separate package
> specs
> is very helpful in getting developers to focus on the notion of an
> interface.  With Java, that seems to be getting lost again.
>
> -Tucker Taft  stt@averstar.com

Re: Another important feature of Ada

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]


"Ed Falis" <efalis@mediaone.net> a �crit dans le message news: PM000376263FFF6F15@Dogen.ne.mediaone.net...
> In the end, it strikes me as a wash, since I can do more or less the
> same in Ada as Eiffel DbC using asserts and (in the case of gnat, pragma
> debug to provide inherited contracts and overrides).  The Eiffel DbC
> capabilities take less work to accomplish the same end.  The Eiffel
> ability to present only the interface in the IDE is less work than
> separately writing specs and bodies.  And fully deferred classes handle
> the pragmatic need for control of interfaces separate from
> implementations by different stakeholders.  Both languages accomplish
> similar goals, and it seems a matter of taste as to which to prefer.
> These languages have more in common than most.
>
The importance of separating specs from bodies is *not* the ability to view them separatly, which can be accomplished with a tool as
you note. It is the ability to compile the spec, and compile users of the spec before even thinking about the implementation.
Therefore you can check the spec, and check that the spec matches the needs without being influenced by implementation constraints
(which often leads to over-specification).

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Another important feature of Ada

[Ed Falis]

Jean-Pierre Rosen wrote:

> The importance of separating specs from bodies is *not* the ability to
> view them separatly, which can be accomplished with a tool as
> you note. It is the ability to compile the spec, and compile users of
> the spec before even thinking about the implementation.
> Therefore you can check the spec, and check that the spec matches the
> needs without being influenced by implementation constraints
> (which often leads to over-specification).

Yes, I should have mentioned that this is easily (and often) done in
Eiffel using completely deferred classes with assertions.  A deferred
class is similar to an abstract tagged type in a package.

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.

- Ed

Re: Another important feature of Ada

[pete]

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.

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.
  

Re: Another important feature of Ada

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]


"pete@nospam" <pete_member@newsguy.com> a �crit dans le message news: 8v78bm01p5t@drn.newsguy.com...
> 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.
Sure, a compiler only detects violation of language rules - which in Ada goes far further than just syntax. Now; if you just use Ada
like any low level language like Java, (i.e. you use only integer and other machine types), then it won't bring you much. If you
really use all the expressive power of Ada to really model your domain problem, then you'll find that quite often, an error in your
analysis will show up as an error when you compile or use your spec. That's certainly how it works for me.

(Was qualifying Java "low level language" a troll ? Well, Java is AFAIK the only language that makes it explicit in its definition
that it can run only on one single machine, and whose basic semantic model is totally dependant on the behaviour of that machine.
The fact that this machine can be emulated on other machines is irrelevant).

> 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 is exactly what we try to avoid, and may mean that maybe you just didn't use Ada to the full extent of its expressive power.
Sure, an interface is never perfect right from the start, but the requirements dictate the interface, and you don't need any body to
check that. Note also that the separation of specs and body make it extremely convenient to first develop a prototype body just to
check dynamic semantic, then provide the actual implementation. Since you don't duplicate the spec, you are sure that the prototype
and the actual match.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Another important feature of Ada

[James Rogers]

"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

Re: Another important feature of Ada

[Ray Blaak]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:
> "pete@nospam" wrote:
> > 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. 

So says the official dogma. 

It sounds good on paper, but in my experience almost all interfaces need some
modification after coding starts and people can actually start using it.

I suppose you could say that I am unfortunate enough to have always worked on
projects with process problems, but I don't think so. The need for
modifications happen even on rabidly paranoid air traffic control projects
whose process (I think) is excellent.

Certainly the major design aspects of an interface should have been worked out
in advance, but the details due to language and environment can drive usage
patterns in particular ways that the designers simply cannot forsee until
coding (e.g. "oh wow! this 3rd party library expects to be able to cache its
data; I guess our data items need to be able to be cacheable across threads
after all").

Instead, it is better to always expect change, and to struture your designs
and abstractions so that they can readily be augmented, reimplemented, etc.

New requirements always happen. Unexpected gotchas always get you.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Another important feature of Ada

[Robert Dewar]

In article <u66ljih85.fsf@infomatch.com>,
  Ray Blaak <blaak@infomatch.com> wrote:

> It sounds good on paper, but in my experience almost all
> interfaces need some modification after coding starts and
> people can actually start using it.

That's too pessimistic in the opposite direction. Whether
interfaces can remain stable depends on several things:

  1. The quality and effort of work to design the interfaces
  2. How well defined the project is
  3. How well organized the project is
  4. Cohesiveness of the team doing the work

Certainly I can give a counter example. In the mid 70's I
did a real time operating system, PD/FMS for Incoterm/Honeywell.
Itwas roughly similar to say the VxWorks kernel, with a complete
set of tools (assemblers, linkers, file system including full
indexed files, system utilities, editor, shells etc) to support
program development.

The entire system was approximately half a million lines of
assembly language, including comments, and it was perhaps
half comments.

The way I proceeded was first to write the entire programmers
reference manual for the kernel with full details of all
callings sequences for thread scheduling etc, and the full
users manual for the program development system. These manuals
were edited into something very close to the final form in which
they were delivered to customers, with discussion on details
*before a single line of code was written*, and the only changes
were very minor (mostly style editing) from then to the final
release. The system was quite successful and was used in some
10,000 sites. My favorite note was from one person who some
years later was forced to switch from PD/FMS to Unix, and was
complaining that it seemed a big step backwards :-)

Of course it helps to have a one person project, since it is
easier to keep everything under control and organized, but I
think this same discipline can be applied to many other
projects.

I would agree you can't achieve it with all projects, but it is
a legitimate and reasonably goal, and it is giving up too easily
to decide that it will fail in "almost all" cases.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Another important feature of Ada

[Ehud Lamm]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:8va2tf$c9l$1@nnrp1.deja.com...
> In article <u66ljih85.fsf@infomatch.com>,
>   Ray Blaak <blaak@infomatch.com> wrote:
>
> > It sounds good on paper, but in my experience almost all
> > interfaces need some modification after coding starts and
> > people can actually start using it.
>
> That's too pessimistic in the opposite direction. Whether
> interfaces can remain stable depends on several things:
>
[snip]
>
> Certainly I can give a counter example. In the mid 70's I
> did a real time operating system, PD/FMS for Incoterm/Honeywell.
> Itwas roughly similar to say the VxWorks kernel, with a complete
> set of tools (assemblers, linkers, file system including full
> indexed files, system utilities, editor, shells etc) to support
> program development.

[snip]
>
> The way I proceeded was first to write the entire programmers
> reference manual for the kernel with full details of all
> callings sequences for thread scheduling etc, and the full
> users manual for the program development system. These manuals
> were edited into something very close to the final form in which
> they were delivered to customers, with discussion on details
> *before a single line of code was written*, and the only changes
> were very minor (mostly style editing) from then to the final
> release.

This reminds my of Brook's discussion of OS/360 in the "The Mythical
Man-Month."
I totally agree with the approach you describe.
One thing I think important to consider is that there are several levels of
interfaces inside a (complex) SW system. I am still not sure that they are
all really in the same family, aside from the very general trait of being
interfaces. Some interface, as we all know, are between two internal
components. Indeed, one thing I find problematic for some students is
realizing that even if a component is internal, it had better be documented
(at least in a cursory way), and seperated from the code using it (even if
there is currently one user).

Why am I belaboring all of this?  Becuase the "low level" internal
interfaces are usually those that people tend to think can be changed
(sometimes each day...), and they are usually those that seem not to be
documented. Survey: How many sw projects that use stacks, document their
"stack" interface (assume these stacks are invisible to users)?
Not that I am saying this is good SE. But we should realize this happens,
even in pretty well organized projects (not the best, but many good
projects).

I am wonderring about enhancing the support for different levels of
interfaces. My gut feeling is that the current state of the art in language
design is not there yet.
(Of course, as you example shows, you can do it all - and well - in assembly
language).


--
Ehud Lamm   mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <==  Me!

Re: Another important feature of Ada

[Ray Blaak]

Robert Dewar <robert_dewar@my-deja.com> writes:
> I would agree you can't achieve it with all projects, but it is
> a legitimate and reasonably goal, and it is giving up too easily
> to decide that it will fail in "almost all" cases.

Certainly you should try very hard to get things correct right up front.

What I object to, however, is the idea that changes that happen once coding
starts is necessarily a sign of process problems. It very well could be, but
not necessarily so.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Another important feature of Ada

[Robert Dewar]

In article <u8zqd19xu.fsf@infomatch.com>,
  Ray Blaak <blaak@infomatch.com> wrote:
> What I object to, however, is the idea that changes that
> happen once coding starts is necessarily a sign of process
> problems. It very well could be, but not necessarily so.

Indeed -- if the customer changes their minds about what they
want, if all you can do is to refuse to adapt and mutter
something about "process problems", you are hardly being
responsive :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Another important feature of Ada

[Ehud Lamm]

Ray Blaak <blaak@infomatch.com> wrote in message
news:u66ljih85.fsf@infomatch.com...
> Instead, it is better to always expect change, and to struture your
designs
> and abstractions so that they can readily be augmented, reimplemented,
etc.
>

I agree. Expect change, but try to avoid the need for it.
You can achieve both goals.


--
Ehud Lamm   mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <==  Me!

Re: Another important feature of Ada

[David Starner]

On Sun, 19 Nov 2000 20:24:27 GMT, James Rogers wrote:
>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. 

It depends on your system. If you're building something like the
air traffic control system someone was talking about, with a clear
design and only maintaince updates, then, yes, it's a process problem.
But Linux's original design goals (runs on 386, works for Linus) differ
enormously from the current requirements. To blame Linus Torvalds for
that is basically to blame him for not being omniscient. Likewise with
Windows ("the average user couldn't care less whether we support TCP/IP") 
and Netscape ("like anyone's going to use a mail reader that comes with 
their web browser"). 

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
As centuries of pulp novels and late-night Christian broadcasting have taught 
us, anything we don't understand can be used for the purposes of Evil.
	-- Kenneth Hite, Suppressed Transmissions

Re: Another important feature of Ada

[Karel Thoenissen]

Ed Falis schreef:

> Jean-Pierre Rosen wrote:
>
> > The importance of separating specs from bodies is *not* the ability to
> > view them separatly, which can be accomplished with a tool as
> > you note. It is the ability to compile the spec, and compile users of
> > the spec before even thinking about the implementation.
> > Therefore you can check the spec, and check that the spec matches the
> > needs without being influenced by implementation constraints
> > (which often leads to over-specification).
>
> Yes, I should have mentioned that this is easily (and often) done in
> Eiffel using completely deferred classes with assertions.  A deferred
> class is similar to an abstract tagged type in a package.
>
> 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.
>
> - Ed

True, but at the cost of doubling the number of classes in the hierarchy and
spilling the name space.



--

Groeten, Karel Th�nissen

Re: Another important feature of Ada

[mjsilva]

In article <3A12041B.BCFD8CA0@worldnet.att.net>,
  James Rogers <jimmaureenrogers@worldnet.att.net> wrote:
> I have been following a thread between comp.lang.eiffel and
> comp.lang.c++.moderated. The thread is boiling down to a discussion of
> the virtues and vices of separating interface from implementation.
>
> The points being made against sepration of interface and
implementation
> focus on a concept that duplication of code is BAD, and separation
> of interface and implementation requires some duplication of code.

I wonder how it could be otherwise?

>...
> Eiffel programmers feel separation of interface and implemenation is
> not beneficial because large Eiffel programs have been constructed
> without this feature.

I would expect Eiffel programmers of all people to appreciate that an
interface is a form of contract!

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Another important feature of Ada

[Brian Rogoff]

On Wed, 15 Nov 2000 mjsilva@my-deja.com wrote:
> In article <3A12041B.BCFD8CA0@worldnet.att.net>,
>   James Rogers <jimmaureenrogers@worldnet.att.net> wrote:
> > I have been following a thread between comp.lang.eiffel and
> > comp.lang.c++.moderated. The thread is boiling down to a discussion of
> > the virtues and vices of separating interface from implementation.
> >
> > The points being made against sepration of interface and
> implementation
> > focus on a concept that duplication of code is BAD, and separation
> > of interface and implementation requires some duplication of code.
> 
> I wonder how it could be otherwise?

In Ocaml, the interface file contains ony the type signature of functions
in the implementation file, and there is no need to repeat the type
information again in the implementation file. So admittedly there is some 
duplication (the name of a function) but much less than in Ada. There is 
actually no need to right a .mli file (equivalent to a .ads in GNAT) for 
each .ml (= .adb) unless you want to restrict what is visible or provide 
the ability for others to compile without the full implementation. 

However, this duplication has never been a significant issue for me in
Ada, or even C (my C code is very Ada-like) so I often wonder why people 
whine about this so much. I did a bit of programming in Sather and Eiffel
a while ago and I have to admit that while there are lots of nice features
in those languages I prefer Ada, and this separation, redundancy and all, 
plays a large part in that preference. 

-- Brian

Re: Another important feature of Ada

[Scott Ingram]

Brian Rogoff wrote:

> Ada, or even C (my C code is very Ada-like) so I often wonder why people

During a break at SIGAda 2000, a small group of us got a chuckle out of
the
fact that our C code looks suspiciously like Ada :-)
-- 
Scott Ingram
Vice-Chair, Baltimore SIGAda
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: Another important feature of Ada

[Lao Xiao Hai]

James Rogers wrote:

> I have been following a thread between comp.lang.eiffel and
> comp.lang.c++.moderated. The thread is boiling down to a discussion of
> the virtues and vices of separating interface from implementation.
>
> The points being made against sepration of interface and implementation
> focus on a concept that duplication of code is BAD, and separation
> of interface and implementation requires some duplication of code.

First, I like much of the Eiffel language design and would like to see
Ada adopt a few of its features.   Second,  I prefer the Ada model of
physically separating the interface from the implementation.   In
reliability
theory, there is a notion of parallel redundancy that is often introduced
to improve the chances of a correct result.   I see Ada compilation model
as somewhat analogous to the parallel redundancy practice.

On large-scale software development projects, where more than one person
is engaged in  developing the code, this redundancy serves as an additional

level of checking between specification and implementation.

While this same effect can be achieved, to some extent in Eiffel, and to a
much lessor extent in C++, Ada is unique in its enforcement.   Ada does not
even
allow implementation code in the specification.  The other languages
mentioned
do permit it.   C++ even requires implementation code in the class
definition
under some silly circumstances

We are dealing here with programmers, most of whom are endowed with a
certain
measure of humanity.   With human programmers, if something can be done it
will be.   This includes succumbing to the temptation to start implementing
algorithmic
code too early in the process.  I am as guilty as anyone else of thinking
about how
I plan to solve a problem before fully considering what problem I am trying
to solve.

Separating the specification from the implementation presents a simple but
effective
obstacle to premature implementation.   Ada, as readers of this forum
understand,
even allows us to defer implementations to small separately compiled
subunits which,
in-turn, provide excellent opportunities for controlling dependencies, as
well as focusing
longer on the "what" before getting involved in the "how.".

Eiffel programmers will retort that they can do the same thing.    I agree,
they can.  However,
being able to do something and doing it are two different things.  Ada
requires the separation.
The argument about duplication of code is not very convincing. Are we
looking for ways
to make coding easier or are we looking for a language design that enforces
a higher level of
discipline in the software engineering process?

Richard Riehle

Re: Another important feature of Ada

[Michel Gauthier]

In article <3A12041B.BCFD8CA0@worldnet.att.net>, James Rogers
<jimmaureenrogers@worldnet.att.net> wrote:

>>  I have been following a thread between comp.lang.eiffel and
>>  comp.lang.c++.moderated. The thread is boiling down to a discussion of
>>  the virtues and vices of separating interface from implementation.
>>  
>>  [...]

I might have missed some reply, but I am surprised that 
nobody have written about teams working in parallel for using 
and coding after a common 'contract' has been accepted.

Is there some industrial comments about this idea ?

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
83, rue d'Isle / F-87000 Limoges
telephone +33 555 43 69 73
fax +33 555 43 69 77
----------          ----------          ----------          ----------
Nous n'etions pas dans la langueur,
nous ne sombrons pas dans l'allegresse.
----------          ----------          ----------          ----------