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

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

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