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: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 1994-09-29 18:42:39 PST Newsgroups: comp.lang.ada,comp.object,comp.lang.c++ Path: bga.com!news.sprintlink.net!howland.reston.ans.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: Thu, 29 Sep 1994 13:35:26 GMT Message-ID: <1994Sep29.133526.2134@swlvx2.msd.ray.com> References: <1994Sep27.165203.9192@swlvx2.msd.ray.com> <36bt0c$17oo@watnews1.watson.ibm.com> <1994Sep29.103358@di.epfl.ch> 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:6316 comp.object:6900 comp.lang.c++:31015 Date: 1994-09-29T13:35:26+00:00 List-Id: MK = Magnus.Kempe@di.epfl.ch (Magnus Kempe) writes: MK>Norm's solution could be further improved as follows: MK> MK>: One variation on this is to declare recursive types meant to serve as the MK>: parents of types Employee and Office, but to provide no operations for MK>: these recursive types. Then, in child packages, declare Employee and MK>: Office themselves as derived types and declare primitive operations in MK>: those child packages: MK> MK>Since this couple of recursive types is strictly internal to the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MK>abstraction "employee and his office", I recommend that they be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Not true. The premise of my original question was that the binary association between Employee and Office is a public feature fully visible to their clients -- and they could even include each other as clients! Maybe the *implementation* of this binary association is strictly internal to the abstraction (I agree that it should be), but the *existence* of this binary association should be a visible part of this abstraction. In other words, the interface to the Employee class should include some subprogram(s) that allow(s) a client to fetch the identity of (a pointer to) the associated Office. Likewise the interface to the Office class should include some subprogram(s) that allow(s) a client to fetch the identity of (a pointer to) the associated Employee. And the interface to both classes should include some subprogram(s) that allow a client to establish an association between a given Office and a given Employee, in such a way as to always guarantee the following invariant assertion: For any given Employee "E" and Office "O", E occupies O if and only if O is occupied by E. MK>declared as abstract and hidden in the private part of the parent MK>package (Yes, this compiles with GNAT): MK> MK> package Company is MK> private MK> type Employee_Parent; MK> type Employee_Pointer is access all Employee_Parent'Class; MK> MK> type Office_Parent; MK> type Office_Pointer is access all Office_Parent'Class; MK> MK> type Employee_Parent is abstract tagged MK> record MK> Its_Occupied_Office : Office_Pointer; MK> end record; MK> MK> type Office_Parent is abstract tagged MK> record MK> Its_Occupying_Employee : Employee_Pointer; MK> end record; MK> end Company; MK> MK>The rest of Norm's solution doesn't change; the couple of abstractions MK>Employee and Office is declared in two child units of Company. To the MK>client programmer, the encapsulation is strong but the relationship MK>between the two abstractions is quite apparent because they are exported MK>by the Company.* subsystem (a hierarchy of packages). Unfortunately, hiding the pointer types within the private part of the parent prevents them from being visible to clients, even via child packages. This defeats the whole purpose of having a mutually recursive *abstraction* -- that is, something that provides an *interface* to some useful services while encapsulating the *implementation* of those services. MK>-- MK>Magnus Kempe "I know not what course others may take, but as for me, MK>Magnus.Kempe@di.epfl.ch Give me Liberty... or give me Death!" -- Patrick Henry -- 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."); --------------------------------------------------------------------------------