From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8bb81cae35ee307f X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Package Parts [was: Ada GC and a bunch of other stuff] Date: 1996/02/23 Message-ID: #1/1 X-Deja-AN: 140834199 references: <31273ED6.B9B@flash.net> <4ggpkg$bl4@dayuc.dayton.saic.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-02-23T00:00:00+00:00 List-Id: In article <4ggpkg$bl4@dayuc.dayton.saic.com>, John G. Volan 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