Uncle

[chipr@niestu.com (Chip Richards)]

I undertook this project with complete confidence that it was fairly
straightforward, and well within my capabilities.  Now, I am having doubts.
I'm converting a small body of C++ code to Ada.  I've done precious little C++
coding, yet I feel as if I understand pretty much completely what the original
code is doing.  But when I try to express those concepts in Ada, I find myself
tangled in a thorn bush of primitive operations, abstract types, and circular
elaboration dependencies.  I continue to believe that this project isn't
inherently harder to do in Ada than in C++, but at this point in my life,
apparently it's harder for *me*.  And it's not the code per se that is
troubling me, it's how to *structure* it--how (and perhaps whether) to break
it up into separate packages.  If I were willing to make it all one huge
package, I'd be done by now.

For reference, this is a small GUI toolkit named PUI.  Both the original C++
code and my current mangled efforts are on the web, the former at
"http://web2.airmail.net/sjbaker1/pui/" and the latter at
"http://www.niestu.com/languages/oglada/apui/apui-dev.html".  If anyone is
interested enough in these problems to want to see simpler, abstracted
examples, I'd be happy to provide them.  There just aren't any Ada people
around me that I can discuss this with, so I'm turning to the newsgroup.  (And
thanks to David Hoos, who got me out of an earlier rut.  It's not his fault
that I'm now in a much larger ditch. <grin>)  And in case anyone is wondering,
the problems arise entirely from me, and not from the original code--Steve
Baker, author of PUI, is a master with C++.  His code is as clean as anyone
could want.

On to specific questions.  First, there's an Object type (a tagged record--an
*abstract private* tagged record at the moment, because that seemed like the
right thing to do), from which about half the various widget types are
derived, and a Composite type (called "puInterface" in the original code)
which is derived from Object, and from which the rest of the widgets are
derived.  Composite adds a pointer to a list of child Object items, and each
Object contains a pointer to its parent Composite.  Since the two types are
interdependent in this way, they must be declared in the same package spec,
right?  No other choice?  So my urge to make Composites a child package off
Objects is misguided?

Right now, Object and Composite are defined in the topmost package, called
"PUI", along with their primitive operations.  There are child packages
PUI.Objects and PUI.Composites, which define various related procedures, but
only "internal" ones--all the user-visible subprograms that operate directly
on those two types are also in package PUI.  I already don't like that
structure, but I've got more pressing problems at the moment.

One suggestion I've received is to combine Object and Composite into a single
type.  I could do that, but it seems as if it would lose some information--all
Composites are Objects, but not all Objects are Composites.

In fact, my overall tendency is to want to put each of the various types and
their associated subprograms together in separate packages.  And because most
of the "major" user-visible types are derived from Object (which is itself not
used at the "user" level), I tend to think in terms of defining Object in a
"parent" package, and making all the other packages children of it.  However,
I'm starting to get the idea that this isn't a very good plan.  Every time I
try to split the code into neat chunks, a powerful force seems to want me to
glom them into one giant package.  Ugh.

Many of my problems doubtless stem from my practice of patterning the Ada
structure after the C++ structure.  I mean, the C++ is broken up into (fairly)
tidy separate little source files, which seemed like a nice structure to use.
This is starting to seem like more and more of a mistake, and my current
temptation is to rip the code apart and bolt it back together some other way.

But, which way?  Should I create independent packages like, say, Objects (as
opposed to the current PUI.Objects) and Boxes, and include *those* in a main
"PUI" package?  The problem with that is, for user programs to see primitive
ops of type Object, they would have to "with" package Objects.  Now, to my way
of thinking, that's just silly--users don't use "Objects", they use "Buttons"
and "Sliders" and so forth.  Including a seemingly useless package because the
language makes you do it that way seems wrong to me.

I'm pretty sure it's me and not the language, however, and I'm sure some of
you out there can do this stuff in your sleep.  I'm open to any suggestions.
In case it matters, I'm using GNAT 3.10p under Linux.  If you've gotten this
far, thanks very much for your time!

-- 
Chip