Re: circular unit dependency

[mheaney@ni.net (Matthew Heaney)]

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
<mailto:matthew_heaney@acm.org>
(818) 985-1271