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: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,66253344eaef63db X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 1994-09-30 22:21:53 PST Newsgroups: comp.lang.ada,comp.object,comp.lang.c++ Path: bga.com!news.sprintlink.net!howland.reston.ans.net!cs.utexas.edu!convex!news.duke.edu!MathWorks.Com!news2.near.net!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG) Date: Sat, 1 Oct 1994 01:47:58 GMT Message-ID: <1994Oct1.014758.10687@swlvx2.msd.ray.com> References: <1994Sep27.165203.9192@swlvx2.msd.ray.com> <36bt0c$17oo@watnews1.watson.ibm.com> <1994Sep29.103358@di.epfl.ch> <1994Sep29.133526.2134@swlvx2.msd.ray.com> <36hsc5$g1q@watnews1.watson.ibm.com> Sender: news@swlvx2.msd.ray.com (NEWS USER) Keywords: Ada 9X, C++, object-oriented Organization: Raytheon Company, Tewksbury, MA Xref: bga.com comp.lang.ada:6351 comp.object:6944 comp.lang.c++:31191 Date: 1994-10-01T01:47:58+00:00 List-Id: ncohen@watson.ibm.com (Norman H. Cohen) writes: >The five lines just above seem to contradict your earlier statement that >the pointer types (the imnplementation of the binary association between >offices and employees) should be private, so I'll assume you really meant >what you said the first time and not the second time. Pasting together >bits and pieces of solutions proposed by Mark Biggar, Magnus Kempe, and >me, isn't the following all that you're really looking for? Well, I guess I haven't been very clear, sorry about that. Maybe the post I just sent out with all the pictures will help, but let me try again here. Your solution is perfectly fine in terms of what I think you thought I wanted :-). I described the problem in terms of a single association and two classes, and if that's all there were to it, capturing the mutual dependency as an abstraction works well. But you see, I always had in mind expanding this out to many classes with many interrelationships, and I don't think your scheme will scale up well. Suppose, instead of just writing package "Employees_And_Offices", we had to write package "Company". Suppose we tried to support not only Employees and Offices, but also other things in the problem domain of Company management. Things like Memos and Meetings and Job_Descriptions and Inventories and Stock and Benefits and so on and on and on ... (Please bear with me, I'm not even going to try to make this a realistic example, nor do I propose that you would really want to cover this particular problem domain this way. But for the sake of argument, here goes.) with Sets; package Company is type Employee_Parent is abstract tagged private; type Employee_Pointer is access Employee_Parent'Class; package Employee_Sets is new Sets (Employee_Pointer); type Office_Parent is abstract tagged private; type Office_Pointer is access Office_Parent'Class; package Office_Sets is new Sets (Office_Pointer); type Memo_Parent is abstract tagged private; type Memo_Pointer is access Memo_Parent'Class; package Memo_Sets is new Sets (Memo_Pointer): type Meeting_Parent is abstract tagged private; type Meeting_Pointer is access Meeting_Parent'Class; package Meeting_Sets is new Sets (Meeting_Pointer); type Job_Description_Parent is abstract tagged private; type Job_Description_Pointer is access Job_Description_Parent'Class; package Job_Description_Sets is new Sets (Job_Description_Pointer); type Inventory_Parent is abstract tagged private; type Inventory_Pointer is access Inventory_Parent'Class; package Inventory_Sets is new Sets (Inventory_Pointer); ... ad nauseum -- Nondispatching operations concerned with the relationships -- between offices and employees, -- between memos and employees, -- between memos and meetings, -- between meetings and employees, -- between employees and job descriptions, -- between employees and inventories, -- between inventories and stock, -- between employees and benefits, -- ... ad nauseum private type Employee_Parent is tagged record Its_Job_Description : Job_Description_Pointer; Its_Occupied_Office : Office_Pointer; Its_Sent_Memos : Memo_Sets.Set; Its_Received_Memos : Memo_Sets.Set; Its_Attended_Meetings : Meeting_Sets.Set; Its_Coordinated_Meetings : Meeting_Sets.Set; ... end record; type Office_Parent is tagged record Its_Occupying_Employee: Employee_Pointer; Its_Employee_Occupancy_Memos : Memo_Sets.Set; ... end record; type Memo_Parent is tagged record Its_Sending_Employee : Employee_Pointer; Its_Receiving_Employees : Employee_Sets.Set; ... end record; type Meeting_Parent is tagged record Its_Announcement_Memo : Memo_Pointer; Its_Followup_Memo : Memo_Pointer; Its_Atteding_Employees : Employee_Sets.Set; Its_Coordinating_Employee : Employee_Pointer; ... end record; type Job_Description is tagged record Its_Described_Employees : Employee_Sets.Set; end record; . . . ad nauseum end Company; You see, no matter how nicely you abstract the coupling between Employee and Office, no matter how well you hide the implementation of the links, no matter how well you defer the "other stuff" to the child packages, the fact remains that you are declaring the Employee and Office types in the same declarative region. If a mutually-recursive association forces you to declare two class types (however abstract) in the same declarative region, then the effect is going to be transitive, and it essentially can force you to put the entire semantic network of a large problem domain into one monolithic package. Adding just one more class or association into the network, because of a requirements change, will force you to recompile this package, all its children, all their clients ... possibly the whole application. On the other hand, if we can manage to maintain 1 Package = 1 Class even despite mutual recursion, then we at least have some hope of managing a large, complex problem -- one class at a time. Isn't that what object-orientation is all about? I think, thanks to Tucker and all the rest of you, that I managed to find an Ada9X solution to this problem, a couple of posts back. (If that scheme doesn't work, please let some kind person tell me and put me out of my misery. :-) Perhaps this mutual recursion business is a minor issue, perhaps not, but at least I'm comforted that Ada9X could deal with it if it had to. >-- >Norman H. Cohen ncohen@watson.ibm.com -- John Volan -------------------------------------------------------------------------------- -- Me : Person := (Name => "John Volan", -- Company => "Raytheon Missile Systems Division", -- E_Mail_Address => "jgv@swl.msd.ray.com", -- Affiliation => "Enthusiastic member of Team Ada!", -- Humorous_Disclaimer => "These opinions are undefined " & -- "by my employer and therefore " & -- "any use of them would be " & -- "totally erroneous."); --------------------------------------------------------------------------------