Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG)

[jgv@swl.msd.ray.com (John Volan)]

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.");
--------------------------------------------------------------------------------