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,18f6de557e6897b2 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: circular unit dependency Date: 1997/06/05 Message-ID: #1/1 X-Deja-AN: 246273802 References: <3386d96f.171920@noticias.ibernet.es> <9A7E8196B8D7EE83.E6C868B798076E45.6F1AD9E8B3E01F66@library-proxy.airnews.net> <33932F31.4399@sprintmail.com> <3393D0E1.AC9@sprintmail.com> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-06-05T00:00:00+00:00 List-Id: In article <3393D0E1.AC9@sprintmail.com>, johnvolan@sprintmail.com wrote: >I guess you meant "deficiencies". (Hey, if you're going to nit-pick over >word usage...) I guess it's time for me to install my spell-checker, which I got as a Christmas gift! I've been studying for the GRE, and I've had to memorize thousands of words! Funny that that should be a criterion for getting into grad school. You'd think that they would prefer I spend my time studying the theory of machines and computation. They didn't even ask for any sample code! But I digress. >Perhaps you just haven't worked on the kinds of problems where this >issue arises. There are a lot of ways to skirt the issue (see section 3 >of my FAQ for a few). But there are just some domains where this >pattern is the most straightforward one, the one that preserves the most >abstractions. Perhaps that's true. Bob Eachus and those guys gave examples the last time we...um..."discussed" this ...um.. "issue" in the language, where recursive packages neatly solved the problem. Right now I'm doing a job for a client who insisted that each ADT get its own package (even if it were a nested one), even when colocating the types would have been the most natural solution. The result is a bloody mess. The example is of a queue and its iterator. Obviously the iterator has to know the representation of the queue, so it can iterate over it. But the queue also keeps track of the iterators that have registered with it, so that it can adjust the pointer if an element is removed from the queue. Now, this is certainly not the smartest way to do iteration (they didn't need all that power, nor the attendent complexity), but the queue abstraction was made unnecessarily complex because it didn't have visibility to the representation of the iterator, which was in a nested package. The simple solution would have been to just put the 2 types together in the same package, so they could see each other's representation. This is the about the only degree of colocation I've ever seen necessary: 2 types that are mutually dependent. I'm not suggesting put "24 types" together in the same package, and agree completely that that would be a bit confusing! (Though the reader of my examples posted on the SIGAda Patterns WG home page should be warned: my toy examples all feature multiple types per package!) My real issue is with this coding convention that's been floating around for years, that says something like "Thou shalt put only one ADT per package." If you blindly apply a rule like that, without any thought at all (like on my current project), then you're going to make your code very complex. The guideline should be stated "Don't put unrelated types together in the same package," because that would increase coupling. (It gives a client interested in only one of the types an unnecessary compilation dependency on the other.) Glib application of the former rule is also a warning sign that the shop isn't really thinking in Ada, and is confusing module and type. Natural and elegant solutions are only effected by immersing oneself in the language, and not fighting its idiosyncrasies. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271