Re: Separate Compilation in Programming Languages

<adaworks@xxxxxxxxxxxxx> writes:

Yes. I agree. When we defer the implementation to the body, there is
no need to recompile anything, unless the implementation is tightly
bound to the specification. The architectural concern is when we
recompile the specification. Any change to the specification will
imply a change to everything dependent upon it.

Right, but in Java, you can always move that dependence into an
implementation of an interface, just like you can move that dependence
down into a package body in Ada.

In your example, you have deferred the dependency to the body of P2.
So there is no need to recompile the spec for P2. However, if the with
clause had been at the specification level of P2, and if the specification
for P1 had changed, there is certainly a danger of an architectural
problem if we did not recompile the specification and body for P2.

Yes, the spec of P2 would need to be recompiled in that case.
I don't see why that's an "architectural problem".

First, the traditional Ada way, using what you like to call "opaque"
types:

Opaque type is not my name for this. It seems to be a commonly accepted
term for the idiom.

Well, the only time I've heard "opaque type" is in the Modula-N context,
and in cases where you have imported the term into the Ada context.
The usual term for this is "stt access types" or "Taft Amendment types",
named after their inventor.

Correct. A change to the implementation does not require a recompilation.
However, a change to the specification does. Also, in the example shown,
you accidentally omitted the word "body" from the implementation unit.

Yes, thanks for pointing out that I forgot "body".

If we change the implementation of the stacks abstraction (i.e. the
package Stacks.Implementation -- spec or body, it doesn't matter), we do
not normally need to recompile the clients.

Note the inadventant omission of the word "body" in the example.

Another missing "body" -- thanks again.

I agree, we do not need to recompile the clients or dependent children
if only the implementation has changed. This is exactly my point. When
the scope clause (with clause) is deferred to the package body, the
dependencies are also deferred to that level. When the dependencies
are at the specification level, and some specification on which there is
a dependency changes, the specification does have to be recompiled.
This is the point of deferring with clauses to the body.

Right. But the point of my example is that you can always defer the
"with" to an implementation of an interface.

In a separate reply, you mentioned generics. In most cases, there is no
reason why a generic cannot be instantiated at the package body level.

I don't agree with that. In my experience, when I declare a type T,
I often want a sequence-of-T, or mapping-of-T, or whatever, exposed to
clients, that is done by generic instantiation.

My contention is that the Ada model of dependency management is far
superior to most other models for the preservation of architectural
stability. Am I alone in this view?

I'm not entirely sure what you mean by "architectural stability" here,
but I guess I'd agree if you changed "far superior" to "slightly more
convenient". ;-)

- Bob
.