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: John G. Volan Subject: Re: Package Parts [was: Ada GC and a bunch of other stuff] Date: 1996/02/22 Message-ID: <4ggpkg$bl4@dayuc.dayton.saic.com>#1/1 X-Deja-AN: 140697818 distribution: world references: <31273ED6.B9B@flash.net> content-type: text/plain; charset=ISO-8859-1 x-xxmessage-id: organization: Science Applications International Corp. (SAIC) mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-02-22T00:00:00+00:00 List-Id: In article <31273ED6.B9B@flash.net> Ken & Virginia Garlington, redhawk@flash.net writes: >I have one question which may have already been answered. If you >have a package in five parts, as in the original example, would you >ever add a sixth part? If so, having to change all the other package >names would seem to be counter-productive from a maintenance standpoint. IMHO, adding a new part to an existing package would mean that you were making a profound change to the structure of the package. Remember that the parts are supposed to constitute a single extended declarative region with an explicitly prescribed sequence. Inserting a new part at the beginning or middle of this sequence affects all the following parts, but even adding a part onto the end of the sequence might have an affect on the preceding parts. I would not be surprised if this forced you to revisit the other parts for reasons beyond just changing their names. (Actually, it's not their "names" that would change. Rather, it's whatever clauses they each use to indicate the total set of parts they all belong to -- in Norman's syntax, it would be the "of Total" clauses). Indeed, I'd be suspicious if the language allowed you made such a profound change _without_ carefully revisiting the other parts. At the very least, the other parts would need to be recompiled. 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"? 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?) (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.) ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------