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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: "John G. Volan" Subject: Re: circular unit dependency Date: 1997/06/03 Message-ID: <33944BC7.969@sprintmail.com>#1/1 X-Deja-AN: 245867469 References: <3386d96f.171920@noticias.ibernet.es> <9A7E8196B8D7EE83.E6C868B798076E45.6F1AD9E8B3E01F66@library-proxy.airnews.net> <33932F31.4399@sprintmail.com> <33942317.2BCD@pseserv6.fw.hac.com> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-06-03T00:00:00+00:00 List-Id: W. Wesley Groleau (Wes) wrote: > > John, > Your example is reasonable, and a solution would be a good thing, > but the problem is not a disaster. I can only remember once in > over ten years that I wished I could separately package two types > but couldn't. Of course it's not a disaster. There are, after all, a variety of avoidance techniques, some of which I enumerate in section [3] of my FAQ. I think what happens is that most Ada programmers naturally fall into the technique suggested by [3.2]: Arbitrarily choose one class to be client-only and the other to be supplier-only, force the association to be one-way. I suspect many Ada programmers are not even conscious that they are doing that. I exploit it whenever I can. It can let you go quite a long time without ever facing the Day of Mutual Reckoning. :-) However, this kind of one-way biasing is somewhat artificial and stilted when, conceptually, the object classes are really peers. The alternative, mutually dependent packages, only _seems_ awkward because of this quirk (or rather, this hole) in the language. If Ada already had one of the enhancements that have been suggested (see section [5]), I wager we wouldn't be having any of these religious debates about how packages were "meant" to be used. I just think, as we begin entering an era of increasingly large and complex domains (e.g., distributed client/server object systems), these kinds of situations will increase in frequency. It would be a good idea to have all our ducks in a row. I believe that separately encapsulated yet mutually dependent object classes are a legitimate design pattern, one that ought to be available as an option within every engineer's repertoire. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Texas Instruments Advanced C3I Systems, San Jose, CA", Work_Email => "johnv@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) "); ------------------------------------------------------------------------