Re: Separate Compilation in Programming Languages


"Robert A Duff" <bobduff@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:wcc63wfpus7.fsf@xxxxxxxxxxxxxxxxxxxxxxx
<adaworks@xxxxxxxxxxxxx> 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


.

Relevant Pages

  • 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: [SV] Interfaces should be compiled or included?
    ... If you're using a virtual interface to connect things to an ... it cannot go in a package. ... You could create a package with a typedef in it for the virtual, ... keeping separate those things that should be separate ...
    (comp.lang.verilog)
  • Re: reason for having separate package.lisp?
    ... reasons given *not* to put the package forms in the same file: ... that you achieve modularity when you *separate* different ... implementations that package.lisp be a separate file. ... you'll achieve a separation of interface and implementation. ...
    (comp.lang.lisp)
  • Re: parent package referring to child
    ... handle this in all Ada's spec. ... That is split the FOO package into smaller files and use the "seperate" ... package body Ch10 is separate; ...
    (comp.lang.ada)
  • Re: object system...
    ... In a typed system you can separate implementation from the interface ... How to express in the language a wish to delegate, A of X to B of Y. ... Performance of hash tables is less predictable, ...
    (comp.object)