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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,66253344eaef63db X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-09-30 22:35:28 PST Newsgroups: comp.lang.ada,comp.object,comp.lang.c++ Path: bga.com!news.sprintlink.net!howland.reston.ans.net!usc!news.cerf.net!shrike.irvine.com!adam From: adam@irvine.com (Adam Beneschan) Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG) In-Reply-To: Magnus.Kempe@di.epfl.ch's message of 29 Sep 1994 13:10:03 GMT References: <1994Sep27.165203.9192@swlvx2.msd.ray.com> <36bt0c$17oo@watnews1.watson.ibm.com> <1994Sep29.103358@di.epfl.ch> <36eebb$jn5@disunms.epfl.ch> Sender: usenet@irvine.com (News Administration) Organization: Irvine Compiler Corp., Irvine, California, USA Date: Sat, 1 Oct 1994 01:24:40 GMT Message-ID: Xref: bga.com comp.lang.ada:6352 comp.object:6946 comp.lang.c++:31195 Date: 1994-10-01T01:24:40+00:00 List-Id: Magnus.Kempe@di.epfl.ch (Magnus Kempe) writes: > John is still not satisfied that Ada 9X has a clean, elegant solution > to his problem (two abstractions, Employee and Office, have a recursive > dependency--how to model/implement that?). I'd like to chime in and say I'm not satisfied either. First, the disclaimers: I'm just starting to learn about OO concepts and Ada 9X, so I may not know entirely what I'm talking about. I certainly don't yet understand the meaning of all the new 9X syntaxes presented in the examples. Certainly, some of my ideas are influenced by what little I know about Eiffel. Also, I'm by no means an expert at language design. However, the solution shown feels like a "workaround", not a clean, elegant solution. I guess it could be called a clean, elegant workaround. My reasoning is as follows: If the dependencies went only one way (an Employee contains a reference to an Office, or vice versa), the implementation would be straightforward. Because there are mutual dependencies, though, a new package Company has to be added. This means that the package Company is there "just to get the Ada language to do what you want", not to represent any concept or abstraction that has anything to do with the application. The Company package doesn't add anything to another programmer's understanding of how the program works--and it may in fact be a hindrance, since it has a name that could mislead one into thinking that it actually has some relevance. Perhaps it would be better to name it Aybnuiyuiwrfnkb or something. Similarly, the example uses inheritance (type Employee is new Employee_Parent is inheritance, right?). As I understand it, inheritance's primary purpose is to model "IS-A" or "IS-A-KIND-OF" relationships between object types (I believe it's sometimes used purely for code reuse, although that seems like a misuse of the concept to me). Here, inheritance doesn't really model anything--it's just something that got set up in order to get things to work. Like the Company package, the use of inheritance here doesn't add anything to one's understanding of the program. I assume that the examples given work correctly. I assume also that they satisfy the really important requirement--namely, that packages other than Employee, including Office, have access to everything the Employee package wishes to put in its interface and to nothing else having to do with Employees (and similarly for Offices). Thus, this is certainly an acceptable workaround for the problem. But "clean" and "elegant"? Maybe I'm being too much of a purist, but I have trouble characterizing something that requires adding this much code that has no meaning to someone reading the program, as elegant. It seems more like a flaw in 9X that things have to be done this way. And based on my experience writing large Ada 83 programs, my gut instinct is that this is the sort of flaw that will be cursed by many 9X users down the line. I also realize that if we tried to make Ada 9X absolutely perfect, it wouldn't be Ada 9X any more but something like Ada 23. :-) What I think John wants (and I concur) is some way for package specifications to use accesses to types in other packages that haven't been compiled yet--sort of like a forward declaration that crosses package boundaries. Perhaps something like this could be added to Ada 0X or whatever the next revision of the language would be. with ...; -- other stuff without Office; -- "without" means that we're referring to a -- package that hasn't been compiled yet package Employee is ... private type Object is tagged record ... -- various components involving that "other stuff" Its_Occupied_Office : Office.Pointer; -- here we're promising that when Office is compiled, -- there will be an ACCESS type named Pointer. This -- will be verified at link time. end record; end Employee; Oh well, just my 2 cents . . . -- Adam (P.S. John, how about we get together and start our own church? :-) -- The above views are my own and do not necessarily represent those of Irvine Compiler Corp.