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,23cf9f1e93744eed X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-26 08:27:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" Newsgroups: comp.lang.ada References: <3F228F3B.9020203@attbi.com> Subject: Re: Need advice re package organization. X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Sat, 26 Jul 2003 11:27:16 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1059233566 24.150.168.167 (Sat, 26 Jul 2003 11:32:46 EDT) NNTP-Posting-Date: Sat, 26 Jul 2003 11:32:46 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:40839 Date: 2003-07-26T11:27:16-04:00 List-Id: "Robert I. Eachus" wrote in message news:3F228F3B.9020203@attbi.com... > Bobby D. Bryant wrote: > > > Any suggestions, either for my specific example or for more general > > considerations? > > The "right" answer to this question tends to be heuristic. One package > is probably too few, one (child) package per final type may be too many. > > If your (final) object types are going to be composed of component > types, you almost certainly want one set of packages of components, and > another of objects. I would start with that organization, and > specialize using child packages if there are types that are difficult to > implement, not generally used, or where collisions between operation > names are going to cause problems when you have a use clause for the > main package. > > Figuring out the best organization is tough, and often you will discover > a problem with the hierarchy you have chosen once you start implementing > it. Don't worry, go ahead and change it. That is what text editors are > for. You don't need to find the perfect decomposition, just avoid bad > ones. And a bad decomposition shows up when it starts making work for > you, rather than eliminating it. > > Of course, whatever organization you choose, you should sketch it out > first, write the package specs, the main program, and then the package > bodies. All of this is good advice. When structuring your packages, keep in the back of your mind the visibility and access rules that Ada insists upon. For example, you'll have to avoid any circular package references (a poor hierarchy will have a package trying to with a package that has already been with-ed by it, creating a circular dependency). Another catch may be a "support" package, that cannot gain access to the necessary types of a set of parent/child packages (due to circular references). Parent/child package relationships themselves can get tricky. From a software design perspective, you want to limit visibility for safety, and yet the child packages enjoy full visibility of the private parts of the parent. Yet, when the same package is moved outside of the parent/child hierarchy, you enjoy the limited visibility you want, but then you may not have the visibility to types and API's that you might need. [As a side note, I sometimes wonder if an enhancement to the Ada0Y language might be to be able to specify a limited visibility of a parent package's object's internals (a la not "protected" type in C++). A protected class in C++ allows derived code to mess with the internals, whereas normally the parent object's elements are a black box. Use of limited visibility helps to reduce code coupling.] I have found the object relationships are easier to define, and these should perhaps be done first (perhaps initially as one package). After this has been "purified/tested", then see how this can be broken down into separate and perhaps "optional" packages and child packages. Package visibility rules make the packaging more difficult, in my own experience. Obviously if the project is huge, you'll want to define the objects and package hierarchy up front (for sanity and quicker development). It might also be stated that this is good practice anyway, and should always be done this way. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg