Re: Separate Compilation in Programming Languages

[<adaworks@sbcglobal.net>]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:ur6f4sb5l.fsf@STRIPCAPStelus.net...
> <adaworks@sbcglobal.net> writes:
>> The issue is about dependencies.   When the class definition and the
>> class implementation are in the same file, any dependent units will
>> have to be compiled when there is a change in that file.    I don't
>> see any capability for managing this kind of dependency in Java.
>
RB> In practice it's not an issue. Compilation is cheap.
RB>
For small software systems this might be true.   However, for large
systems this is not true.  I am thinking in terms of software projects
that require over a million lines of source code and a lot of library
units where the dependencies are significant.  For systems of this
magnitude, where many different programmers are working on the
project, compilation is not cheap.
RB>
RB> But there is a way to manage explicit dependencies: express the public 
facing
RB> APIs in terms of interfaces with implementation classes that truly hide the
RB> actual implementation.
RB>
I considered Interfaces.  They appear, at first glance, to be a solution. 
However,
they fall short of what we are seeking here.   Once the Interface is 
implemented,
the rest of the software still depends on that implementation and there is no
model of separate compilation at that point where one can separate the
specification from the implementation.  The dependency becomes bound to
the implementation of the Interface not to the Interface abstraction.
RB>
RB> This gives a strict separation that gives you the control you were looking
RB> for.Whether that is as convenient or not as Ada is another debate.
RB>
It is not a matter of convenience.   It simply falls short.
RB>
RB> The issue is simply not that serious, partially due to Java's dynamic 
loading
RB> abilities. I can drop a new version in of my library JAR in somewhere, and 
if
RB> the public API signatures have not actually changed I do not in fact need to
RB> recompile.
RB>
RB> In practice however, you do, because it's easy and it catches any unexpected
RB> API changes. But one was still doing "separate compilation".
RB>
But not managing dependencies very well.