Re: Separate Compilation in Programming Languages

[<adaworks@sbcglobal.net>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc63wfpus7.fsf@shell01.TheWorld.com...
> <adaworks@sbcglobal.net> writes:
>
>> My concern is dependency management.
>
> OK, but I still don't fully understand what you're getting at.
> You said elsewhere in this thread that you are NOT concerned with
> recompilation costs.  That's good -- recompilation cost should
> primarily be an implementation concern.
>
Sometimes recompilation costs are important.   This is true for very
large software systems where one does not want to recompile the
entire system for one change somewhere way down in a function
within one package body.

> I'm guessing that your point has nothing to do with "compilation" at
> all, separate or otherwise.  It has to do with the organization of the
> program into separate source files -- specifically separation of spec
> and body (interface and implementation, to use more language-neutral
> terms).  Right?
>
Right.  My primary concern, in this discussion,is with dependency management.

>
> OK, so you like having textually separate spec and body,
> as do I.  But what specific advantages are you talking
> about in this thread?
>
> Readability?  That is, when looking at a client of A, you don't
> need to worry about X,Y,...S.  This is good, but it's got little to do
> with separate compilation.
>
In my view, it does.  The less code I have to look at to make a
change or to understand the code, the better.  Granted, this does
not always work as well as I might like, but it frequently is of
value.
> Source modification?  A change in X could introduce a bug
> into a client of A -- so there really _is_ a dependency
> in that sense.
>
However, the dependency is at the iimplementation level, not at
the specification level.

> One advantage of Ada over some languages (e.g. C) is that the
> implementation can know what source files are part of each program,
> by following the with clauses.  I really hate having to write a make
> file that lists out all the .o files that need to be linked together --
> Ada allows that to be completely automated (that's what gnatmake does).
>
Well, Yes.   If, in one of my separately compiled subprograms within a
package body Q, uses a depth-search routine from a parent package
specification K, and we decide to use the breadth-search instead, there
is no need to alter any part of the package specification of Q.  It remains
stable.

This becomes an architectural issue, as well.   The more stable my
architecture when a change is made to some element of that architecture,
the better for my overall design.

> Something else?
>
> Note that Ada requires some implementation details to appear in the
> package spec -- namely, the stuff that goes in the private part, plus
> the with clauses needed by that private part.  That's ugly, IMHO.
>
Modula-2 solved that problem through the use of opaque types. I
often code opaque types in Ada using access types.   This eliminates
any dependencies at the specification level, in many cases.   As you
know, the private part of a package was a compromise that allows
separate compilation.

We can even create a tagged type as an opaque type, thereby hiding
any implementation details and still making that type extensible.  This
was difficult in Modula-2, so the designers of Modula-3 also had to
make some compromises.   Engineering is always about trade-offs
between conflicting solutions.   Java certainly has its share of trade-offs.
>
> Shrug.  I don't use "is separate" much.  Child packages are almost
> always better, because you can separate the spec _and_ the body,
> and because the parent need not know about the child.  Child packages
> provide the same advantage of being able to "push down" the
> dependencies.
>
I did not mention Child packages, but you are certainly correct that they
are a powerful contributing solution to this issue.   In particular, private
children are a great benefit.   However, in very large software systems,
a million SLOC or more, "is separate" continues to play an important
role.  As noted earlier, specifications should be an architectural concern,
and the more stable an architecture, the better.   Implementation should
be dependent on architecture, not the other way around.

When I want to change the upholstery in my car, I don't want to have to
alter the architecture of that car.   I don't want the performance of the car
to depend on whether I choose Zebra seat covers or chartreuse trim
on green Naugahyde.

>> I don't think this is possible in Java, Eiffel, or C#.
>
> It's possible using interfaces.  Clients of an interface do not depend
> on classes that implement the interface, any more than clients of an Ada
> package spec depend on its body.  You suggested otherwise elsewhere in
> this thread, but I think you're wrong, or else I'm misunderstanding what
> you mean by "depend".
>
> Interfaces are more flexible than spec/body in that they allow multiple
> "bodies".  And of course Ada 2005 has interfaces.  Note that an
> interface will typically be declared in a package spec with no
> corresponding body.
>
Even with an interface, a la Java, once the interface is implemented, the
children dependent on that unit will be dependent on the implementaion,
not on the interface.   And Java still has no way of separating the
specification of that implementing class from its implementation.   In
another forum (comp.lang.programming) someone submitted an
example to show how interfaces would solve this problem, but the
example did not separate interface from implementation..
>
> Eiffel has separate specs and bodies -- except that the spec is
> automatically generated from the body, rather than being written by
> hand.  I prefer to consider the spec to be a source file in its own
> right, as in Ada, but it's not _that_ different from Eiffel.
>
Yes.  In Ada, the specification is most certainly a separate source
file.  As noted earlier, the specifications and the relatioships between
specifications, represent the overall architecture of the software
system.   I'll take another look at Eiffel, a language design I do admire,
and examine this in more detail.   However, at my present understanding,
the implementation and specification do not present the same independence
one finds in Ada.   Perhaps someone will post an example.

Thanks for your details reply.

Richard