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

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <1994Sep29.133526.2134@swlvx2.msd.ray.com>, jgv@swl.msd.ray.com
(John Volan) writes: 

|> 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.
...
|> 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.

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?

   package Employees_And_Offices is

      type Employee_Parent is abstract tagged private;
      type Employee_Pointer is access Employee_Parent'Class;

      type Office_Parent is abstract tagged private;
      type Office_Pointer is access Office_Parent'Class;

      -- Nondispatching  operations concerned with the relationship
      --    between offices and employees: 

      function Office_Occupied_By
         (The_Employee: Employee_Parent'Class) return Office_Pointer;

      function Employee_Occupying
         (The_Office: in Office_Parent'Class) return Employee_Pointer;

      procedure Occupy
         (The_Employee : in Employee_Pointer;
          The_Office   : in Office_Pointer);

   private

      type Employee_Parent is tagged
         record
            Its_Occupied_Office: Office_Pointer;
         end record;

      type Office_Parent is tagged
         record
            Its_Occupying_Employee: Employee_Pointer;
         end record;

   end Employees_And_Offices;


   package Employees_And_Offices.Employees is

      type Employee is new Employee_Parent with private;

      [Operations concerned with the Employee "other stuff"]

   private

      type Employee is new Employee_Parent with
         record
            [the other stuff]
         end record;

   end Employees_And_Offices.Employees;


   package Employees_And_Offices.Offices is

      type Office is new Office_Parent with private;

      [Operations concerned with the Office "other stuff"]

   private

      type Office is new Office_Parent with
         record
            [the other stuff]
         end record;

   end Employees_And_Offices.Offices;

Employee and Office can each see the other's links to itself, but each
type's "other stuff" is hidden from the other.  Outside clients can't
even see the links, just the subprograms for manipulating the links.

--
Norman H. Cohen    ncohen@watson.ibm.com