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,d7888dd6424b687,start X-Google-Attributes: gid103376,public From: chipr@niestu.com (Chip Richards) Subject: Uncle Date: 1998/05/17 Message-ID: <6jlk5s$mob@tomquartz.niestu.com>#1/1 X-Deja-AN: 353947634 Content-Type: text/plain; charset=us-ascii Organization: NiEstu, Phoenix AZ USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-05-17T00:00:00+00:00 List-Id: 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. ) 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