comp.lang.ada
 help / color / mirror / Atom feed
From: John G. Volan <John_Volan@ccmail.dayton.saic.com>
Subject: Re: Package Parts [was: Ada GC and a bunch of other stuff]
Date: 1996/02/22
Date: 1996-02-22T00:00:00+00:00	[thread overview]
Message-ID: <4ggpkg$bl4@dayuc.dayton.saic.com> (raw)
In-Reply-To: 31273ED6.B9B@flash.net

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? :-) " );
------------------------------------------------------------------------




  parent reply	other threads:[~1996-02-22  0:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com>
1996-02-18  0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington
1996-02-21  0:00   ` John G. Volan
1996-02-22  0:00   ` John G. Volan
1996-02-23  0:00     ` Robert A Duff
1996-02-22  0:00   ` John G. Volan [this message]
1996-02-23  0:00     ` Robert A Duff
1996-02-22  0:00 ` John G. Volan
1996-02-22  0:00   ` John G. Volan
1996-02-23  0:00   ` Robert A Duff
1996-02-23  0:00 ` Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox