Re: Separate Compilation in Programming Languages

[Robert A Duff <bobduff@shell01.TheWorld.com>]

<adaworks@sbcglobal.net> 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