Re: circular unit dependency

[mheaney@ni.net (Matthew Heaney)]

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