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/02 Message-ID: #1/1 X-Deja-AN: 245763189 References: <3386d96f.171920@noticias.ibernet.es> <9A7E8196B8D7EE83.E6C868B798076E45.6F1AD9E8B3E01F66@library-proxy.airnews.net> <33932F31.4399@sprintmail.com> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-06-02T00:00:00+00:00 List-Id: In article <33932F31.4399@sprintmail.com>, johnvolan@sprintmail.com wrote: >> Mutual dependency of specs is often an indication that you really should >> have only a single spec, containing the entities from both packages. > >An old, old fallacy, totally obviated by real experience with today's >object-oriented client/supplier applications. Consider distributed OO >software using CORBA: Mutual dependency of IDL interfaces happens all >the time. All the other OO languages out there have no trouble mapping >to that, why should Ada be hobbled in this regard? I'm not sure what you mean by "totally obviated," because obviate means "to make unnecessary." Do you mean "to show to be untrue"? Perhaps you meant "gainsay" or "belie." Oh, yes, I realize the CORBA's IDL allows mutual dependency of modules, but this a really dumb thing to do. But we're comparing apples and oranges. In IDL, an module is a type. That IDL "modules" are allowed to be mutually dependent means that "types" are allowed to by mutually dependent. So be it. To have mutually dependent types in Ada, just put them together in the same package, as you yourself stated. The guys that wrote the Ada IDL binding made a common mistake: they mapped an IDL module (type) to an Ada package. This was a poor choice, and suffers exactly from the problem you describe: how do you have mutual dependencies now, across package boundaries? This is an IDL-to-Ada mapping problem, not a problem with Ada the language. The authors of the mapping made a mistake. What they should have done was to map an IDL type to an Ada type. But no, they didn't do that, and seemed to have C++ on-the-brain when they wrote the mapping document. If the developers of that binding were thinking in Ada, using its "a module is not a type" paradigm, then they should have realized any binding must detect mutual dependencies across types, and properly colocate the mutually dependent types together. Because they failed to do that, they had to solve the mutual dependency problem that they themselves created, and so came up with a klunky scheme whereby each type designates the other through a pointer to a common ancestor. So we've reduced Ada to the typeless paradigm proffered by Smalltalk and Objective-C. They also used the horrible convention of naming types "Object," in a misguided attempt to "fix" Ada by pretending that a package is a type. Well, I have news for you, in Ada a package is not a type, so you better get used to it. If you don't like that, then you're definately using the wrong language, and it does not good for you (nor for the maintenance programmer unlucky enough to inherit your code) to pine for the language to be some other way. To try to separate mutually dependent types across package boundaries will only obfuscate the code, as evidenced by the pointer-to-common-ancestor technique, which wouldn't have been necessary had they done the mapping properly. Would allowing dependencies across package boundaries be better? Sure! I'm all for it. But that's a far different thing from saying that Ada has some kind of "with'ing problem" (which it does not). Somehow I manage to program every day in Ada, thank you very much, in spite of Ada's "difficiencies." -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271