Re: Separate Compilation in Programming Languages

[<adaworks@sbcglobal.net>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccmyppg7yd.fsf@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.
>
Even if this completely accurate, the vast majority of Java applications
use only a small number of packages that consist of interfaces.  The
rest of the design does not use the Interface model.   For those classes,
in those packages, the dependency problem is not only possible but,
after doing some additional research today, I find is fairly common.

>> 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".
>
It is an architectural problem because, in Java, a corrupted dependency,
something that apparently actually occurs in large-scale Java designs,
is also going to corrupt the architecture of the software.  As noted in
a separate post, this problem has required the introduction of special
dependency management tools such as Ivy, Maven, and Ant -- and
these tools are not yet able to detect all the problems though they are
getting better.

Every software entity has an architecture, planned or ad hoc.  One of the
more important aspects of an architecture is to take every action possible
to reduce or manage dependencies between the artifacts of that
architecture.   The separate compilation model of Ada does that better
than most other languages.  Modula has some virtues in this respect.
However, the research I have been doing on Java leads me to believe
that the language has significant weaknesses in architectural stability
for large-scale systems.   There are quite a few articles on the Internet
describing these problems..
>
> Right.  But the point of my example is that you can always defer the
> "with" to an implementation of an interface.
>
Even if we allow for the benefit of the Interface in this situation, we have not
dealt with the larger body of a Java program that is not built using Interfaces.

>> 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.
>
But that does not have to be instantiated at the package spec level.  In many
cases, the instantiation is possible, and preferred at the body level.  Granted,
we sometimes have to instantiate at the spec level,  but not always.  Java
templates are usually instantiated at the specification level, and that most
certainly introduces a level of dependency with system-wide effects.

>> 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". ;-)
>
Architectural stability implies that, except under extraordinary circumstances,
any change to some artifact of the architecture will have minimal impact on
the rest of that architecture.   This is one valuable property of Ada's ability
to let us defer most of our dependencies to the lowest level of the design
possible.  This is not a property of Java, C++, or most other languages
in current use today.  Even incremental compilation falls a little short. Oh,
and does Rational Apex  still support incremental compilation in Ada? GNAT
is not the only Ada environment around.

Richard Riehle