Re: Package Parts [was: Ada GC and a bunch of other stuff]

[bobduff@world.std.com (Robert A Duff)]

In article <4ggpkg$bl4@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>IMHO, adding a new part to an existing package would mean that you were
>making a profound change to the structure of the package.
>...
>Indeed, I'd be suspicious if the language allowed you
>made such a profound change _without_ carefully revisiting the other
>parts.

Then I guess you're suspicious of child packages, which allow you allow
you to add new parts *without* modifying the existing stuff.

>...  At the very least, the other parts would need to be recompiled.

...and without recompiling the existing stuff.

>As an analogy, consider what happens if you, say, add a new procedure
>declaration into an existing package spec.  Ada will force you to
>revisit the existing body of the package and add the corresponding
>procedure body.  Is being forced to do this "counterproductive"?

Yes.  This was recognized as a real problem with Ada 83, which is why
child packages were invented.  (Part of the problem can be solved with
incremental compilation, but incremental compilers aren't easy to
write.)

>...  It
>does take a certain amount of effort to write that procedure body, but
>isn't it worth it to keep the spec and body of a package consistent
>with each other?  What would the cost be in maintainability if Ada were
>more lax about this?  (Is it true that you can declare a member
>function in C++ and then neglect to implement a "body" for it?  If so,
>what's the cost in debugging time to catch this kind of error?)

No, I believe that in C++ you will get an error at link time if you do
that.  (In Ada, you will get an error at link time if the entire package
body is missing.)

>(Contrast this with adding a new child unit into an existing hierarchical
>library. That change should not affect existing parent and child units
>any more than introducing an unrelated package would.  At worst, a new
>child unit might try to exploit internal details of its parent in ways
>that would cause parent code to break when both are linked into the
>same program, but the mere existence of a new child unit would not, for
>instance, require the parent unit to be re-compiled.)

OK, now I'm confused.  I don't see the "contrast".  You're building a
subsystem out of multiple pieces.  In one case, you're horrified at the
idea of adding a new piece without having to modify existing pieces, and
in the other case (child packages), you're perfectly happy with that.
It seems to me that in *either* case, when you add a new piece, you
*might* want to modify existing pieces, and you might not.  I don't see
how a language rule requiring you to make a particular modification is
going to help you recognize the logically necessary modifications --
it's just going to cost extra compile time.

You can break things by adding a procedure to a package, but only if you
add some code that calls the new procedure.  And you can break things by
adding a child (your "at worst...") above, but only if you add some code
that references the new stuff.  I don't see any contrast, and I don't
see any need for language rules to get in the way of making changes.

- Bob