Re: Separate Compilation in Programming Languages

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

<adaworks@sbcglobal.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccbq679zah.fsf@shell01.TheWorld.com...
>
> In the example you provided (shown below) you did defer the with clause
> for the Package P1 to the package body of P2.   This illustrates my point.
> If the specification for P1 changes, only the body for P2 needs to be  compiled.
> Had the with clause been at the specification level for P2, and had the
> specification for P1 changed, the entire package would have had to be
> compiled.

Earlier, you said that this conversation was not about compilation
costs, but now you seem quite interested in compilation costs.
That's OK.  So let's talk about compilation costs.  ;-)

I think you miss the point of my example (still shown below).
Package P1 is the interface, and P2 is the implementation
of that interface.  P2 is NOT a client of P1, it's an
implementation of P1!

There are perhaps 37 clients of P1, not shown.  The question is,
if we modify the implementation (i.e. P2) do we need to recompile
those 37 clients.  The answer is "no".

As you point out, if you change the interface, you have to recompile the
implementation.  That's true in my example.  It's also true if
the interface/implementation is split in the more traditional
Ada way (spec/body).

The issue of recompiling the spec of P2 is irrelevant, since it's empty!

> I think the same is true for Java.   If the specification for the Interface is
> changed, everything needs to be recompiled.   In Ada, by deferring the
> with clause to the package body, we only need to re-compile the body.
>
> So, I think your example actually supports my original assertion.  The
> essential point is that changes in the specifications for a package (or
> a Java class) should not require re-compilation of the dependent
> specifications.   Only the implementations should be dependent on
> other specifications.   This has the effect of keeping the high-level
> architecture more stable.
>
>   package P1 is
>         type Iface is interface;
>         ... declare some abstract procedures ...
>     end P1;
>
>     package P2 is
>         pragma Elaborate_Body;
>         -- Note that this package spec can be entirely empty (except we
>         -- need the pragma so we are allowed to have a body).
>         -- So this package spec isn't defining any interface to
>         -- anything at all!
>     end P2;
>
>     with P1;
>     package body P2 is
>         type Impl is new P1.Iface with ...
>         ... override procedures ...
>         ...
>     end P2;
>
>     -- No body for P1!
>
> Then the client can "with P1", and call operations on Iface objects
> without knowing anything about package P2 (neither spec nor body).
> There is no dependence of clients on P2 (unless I'm misunderstanding
> what you mean by "depend").

Let me try a more concrete example -- the trusty stack example.

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

    package Stacks is
        type Stack is private;
        procedure Push(...);
        ...
    private
        type Stack_Rec;
        type Stack is access Stack_Rec;
    end Stacks;

    package Stacks is
        type Stack_Rec is record ...;
        procedure Push(...) is
        begin
           ...
        end Push;
        ...
    end Stacks;

If we change the implementation of the stacks abstraction (i.e. the body
of package Stacks), we do not normally need to recompile the clients.

We can accomplish the same thing with interfaces.  I'll use a child
package this time, just for fun:

    package Stacks is
        type Stack is interface;
        procedure Push(...) is abstract;
        ...
    end Stacks;

    package Stacks.Implementation is
        type Stack_Impl is new Stack with private;
    private
        type Stack_Impl is ...;
        overriding procedure Push(...);
        ...
    end Stacks.Implementation;

    package Stacks.Implementation is

        procedure Push(...) is
        begin
           ...
        end Push;
        ...
    end Stacks.Implementation;

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.

Both ways of writing the stacks abstraction have the same property --
the 37 clients that say "with Stacks" do not need to be recompiled when
we modify the implementation.

The second example matches what is normally done in Java, except that in
Java, we wouldn't split the implementation into two parts.  Note that in
the second example, that split has no value, since there are no clients
of Stacks.Implementation.  In fact, in some cases, we can choose to move
all of the code from the spec of Stacks.Implementation to its body (as I
did in my P1/P2 example), making the spec empty.

(I'm glossing over the fact that there probably needs to be some sort of
factory for creating stack objects, but that's not relevant to my
point.)

- Bob