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 10:01:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!82-43-33-75.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. Date: Sat, 26 Jul 2003 18:03:13 +0100 Message-ID: References: NNTP-Posting-Host: 82-43-33-75.cable.ubr01.croy.blueyonder.co.uk (82.43.33.75) X-Trace: news.uni-berlin.de 1059238876 19650918 82.43.33.75 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:40845 Date: 2003-07-26T18:03:13+01:00 List-Id: "Bobby D. Bryant" wrote in message news:pan.2003.07.26.13.08.25.810488@mail.utexas.edu... > Most of my work with Ada has involved either smallish > programs or simple self-contained library units where a > good package organization was obvious, but now I'm > doing something with several layers of interrelated parts > and I'd like to get some experienced advice on how to > organize my components into packages. > ... > 3) Create a lean parent package and implement each > object in a separate child package, "with"ing the others > as needed. In situations like this, I tend to aim for lots of relatively small packages and subunits. Generally, I'll have one major type, together with its auxiliary types, and the associated operations in one package. Sometimes I'll have or three quite closely coupled types in one package; I'm generally convinced a set of types are closely coupled if there are a lot of operations with a mixture of them as parameters. I like to hive off big bodies (ooer :-) into subunits. At first, it can seem like a right pain doing this, since it is taxing thinking up names of all packages, time consuming creating all the separate files, with their headers and paraphernalia, and so on. In addition, you tend to have to use long-winded extended names a great deal, and you also tend to find that you need to re-organise things half way through, which means lots more creating of files and shuffling about of code. However, I have found through (very ;-) hard experience that as I start getting deeply into a project of any size, my brain starts turning into jelly, and I find it increasingly hard to keep track of what is where. It is then that having a well-organised package and subunit hierarchy pays off in a big way. When you see a call to the procedure Blurg.Boogle.Watcha.Gerrof and you want to look at its body, you know all you have to do is call up "blurg-boogle-watcha-gerrof.adb" and there it is; no searching through reams of code in a giant package body. Hope this is of some help. Best of luck! -- Nick Roberts Jabber: debater@charente.de [ICQ: 159718630]