Re: Separate Compilation in Programming Languages

<adaworks@xxxxxxxxxxxxx> writes:

"Robert A Duff" <bobduff@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:wccbq679zah.fsf@xxxxxxxxxxxxxxxxxxxxxxx

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
.

Relevant Pages

  • Re: Separate Compilation in Programming Languages
    ... for the Package P1 to the package body of P2. ... no need to recompile anything, ... This is not true in the traditional Ada way when the dependencies are ... package Stacks is ...
    (comp.lang.ada)
  • Re: Separate Compilation in Programming Languages
    ... within one package body. ... all, separate or otherwise. ... OK, so you like having textually separate spec and body, ... Clients of an interface do not depend ...
    (comp.lang.ada)
  • Re: Global variables
    ... I have a litte OT question: how do you initialize the Repository? ... first class triggered the Starter class. ... principle of object orientation is to design towards an interface, ... Starter class must not reside in the interface respository package. ...
    (comp.object)
  • Re: static or not?
    ... > Thus, for example, controller.Driver will register its Controller ... then I can strip away an interface from this ... and have it register that interface in the Registry. ... if this is done from class foo, what's foo's package? ...
    (comp.lang.java.help)
  • Re: Classes vs functions
    ... Interfaces were Java's "solution" to multiple inheritance. ... in a way that one class may implement one or more interface. ... PHP; nobody would be obligated to use or abuse it. ... > resource-consuming) to be able to include an entire package. ...
    (comp.lang.php)