Re: Separate Compilation in Programming Languages

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

<adaworks@sbcglobal.net> writes:

> Perhaps.  But I still don't see how one can defer the dependency of a
> Java signature to the implementation of the Java class and prevent
> the need for recompiling the entire architecture when the signature of
> a parent class changes.   The ripple effect through the entire chain
> of dependencies when one of those signatures changes is almost
> certain to be affected by such a change of signature.

I think perhaps what you are missing is that in Java, you can use the
same "trick" all along the chain.  (The "trick" illustrated by the
examples I showed.)

E.g., in Ada, you are advocating something like this:

    E spec (no with's)
    E body (says "with D")

    D spec (no with's)
    D body (says "with C")

    C spec (no with's)
    C body (says "with B")

    B spec (no with's)
    B body (says "with A")

    A spec (no with's)
    A body (no with's)

...to the extent possible, pushing with's into bodies.
So if, say, B spec changes, you need to recompile
B body and C body, but not (down the chain) D or E.
Here, we have 10 source files.

The analogous thing with interfaces is:

    E interface (no with's)
    E.Implementation (says "with D")

    D interface (no with's)
    D.Implementation (says "with C")

    C interface (no with's)
    C.Implementation (says "with B")

    B interface (no with's)
    B.Implementation (says "with A")

    A interface (no with's)
    A.Implementation (no with's)

In Ada, each "implementation" is a spec and a body, whereas in Java it's
just one class file -- but that's irrelevant.  In Ada, we have 15 source
files (5 of which are empty or nearly so), but in Java, only 10, as in
the previous Ada case.

If you change B interface, you have to recompile B.Implementation (spec
and body) and C.Implementation (spec and body), but not anything down
the chain (D/E).

Note that in this method, there are no dependences on the Implementation
packages, or very few.  Clients such as C.Implementation do NOT say
"with B.Implementation"!

(I'm ignoring private parts and generics, which throw a monkey wrench
into the works.)

>...If Java can
> somehow accomodate that change automatically, ...

Ah, maybe that's the problem.  No, it's not automatic.
In Java, you have to choose to split out all those interfaces,
all down the chain.  And you have to take care to make every
implementation class depend on interfaces, rather than other
implementations.  A simpler structure is:

    E (says "with D")

    D (says "with C")

    C (says "with B")

    B (says "with A")

    A (no with's)

(except Java doesn't call it "with").  In this simpler structure, you do
indeed have the ripple effect you're worried about.

>...it must be some
> kind of magic that is not immediately apparent, even to the Java
> developers I know.

It's not magic!  It requires effort.  It is perhaps easier in Ada.
But I think the "trick" (or "technique") is well known among
Java programmers.

- Bob