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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,754871b84ac2a9be X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-10 11:50:39 PST Path: bga.com!news.sprintlink.net!hookup!news.mathworks.com!mvb.saic.com!buckie.ucha!tali.hsc.colorado.edu!boulder!news.coop.net!news.den.mmc.com!news2!pogo.den.mmc.com!rosen Newsgroups: comp.lang.ada Subject: Re: separate embedded procedures? Message-ID: <1995Mar10.195039.8471@news2.den.mmc.com> From: rosen@pogo.den.mmc.com (Jerome D. Rosen) Date: Fri, 10 Mar 1995 19:50:39 GMT Sender: news@news2.den.mmc.com (News Admin) References: Organization: Martin Marietta Astronautics Nntp-Posting-Host: pogo.den.mmc.com Date: 1995-03-10T19:50:39+00:00 List-Id: In article , Tucker Taft wrote: > >By the way, in large systems I have found subunits >to generally be a pain, as well as nesting of units >inside subprograms... > >-Tucker Taft stt@Inmet.com >Intermetrics, Inc. One exception we've found to Tucker's Rule (subunit = pain) is that subunits can be useful in isolating compilation dependencies ("with"-ing) in bodies. That is, if you're stuck with referencing a messy (SYSTEM, UNCHECKED_XXX, MOTIF, X, etc.) or frequently changing (MY_SYSTEMS_ GLOBAL_DECLARATIONS_PKG) package spec somewhere in a body, you can isolate the code requiring the dependency in a procedure and then isolate the procedure in a subunit. This works best when for whatever reason the code in question _must_ have visibility to declarations in the enclosing unit (and thus can't be in a distinct package), the enclosing unit itself is large, and because of the aforementioned dependencies, you find yourself recompiling that large original unit frequently. JRo (Jerome D. Rosen) Granite Sentry Program, Colorado Springs, CO