Re: HELP needed!!

[cjh@petsd.UUCP (Chris Henrich)]

In article <322@louie.udel.EDU> klaiber@udel.EDU (Alexander Klaiber) writes:
>HELP!!!!!
>I am doing a high-level comparison of high-level languages and I've run
>into a severe problem with Ada. What I am trying to do is the following:
>
>Assume I have a generic package linked_list that, given some type "item",
>defines a type "list" which is a list of "item".
>
>I want to write a package that defined two types, A and B and operations on
>these. Now my problem is that both A and B are records and A includes a
>field of type "list of B" and B includes a field of type "list of A". I
>want the lists to be handled by the generic linked_list.
The following pattern is acceptable to at least one validated
compiler (that of Concurrent Computer Corp.):

PACKAGE my_package_1 IS
   TYPE a; -- "incomplete type declarations"
   TYPE b;

   TYPE a_ptr IS ACCESS a; -- about the only thing you can do with
   TYPE b_ptr IS ACCESS b; -- incomplete type declarations

   PACKAGE list_of_a_ptr IS NEW linked_list ( a_ptr );
   PACKAGE list_of_b_ptr IS NEW linked_list ( b_ptr );
 
   TYPE a IS
      RECORD
         xxx: list_of_b_ptr . list; 
      END RECORD;
   TYPE b IS
      RECORD
         xxx: list_of_a_ptr . list;
      END RECORD;
   --- more declarations, including operations on types "a" and "b"
END my_package_1;

Note that your linked lists come out as lists of pointers. 

This design is open to criticism, because it makes both the record
structure and the pointers visible to users of the package.  There is
some advantage to be gained from keeping the innards of "a" and "b"
private.  For one thing, increased freedom in using them to
instantiate other generic units. For another, it allows you to
separate the compilation of "a" and "b".  Here is a scheme that is a
little better from the viewpoint of software engineering:

PACKAGE my_package_2_a IS
   TYPE abstract_a IS PRIVATE;
   -- fundamental operations with abstract_a
PRIVATE
   TYPE record_a;
   TYPE abstract_a IS ACCESS record_a;
END my_package_2_a;

PACKAGE my_package_2_b IS
   TYPE abstract_b IS PRIVATE;
   -- fundamental operations with abstract_b
PRIVATE
   TYPE record_b;
   TYPE abstract_b IS ACCESS record_b;
END my_package_2_b;

-- note how the implementation of "a" depends on the *specification*
-- of "b"
WITH my_package_2_b; USE my_package_2_b;
WITH linked_list;
PACKAGE BODY my_package_2_a IS
   PACKAGE linked_list_b IS NEW linked_list ( abstract_b );
   TYPE record_a IS
      RECORD
         xxx: linked_list_b.list;
      END RECORD;
   -- lots of other implementation details
END my_package_2_a;

WITH my_package_2_a; USE my_package_2_a;
WITH linked_list;
PACKAGE BODY my_package_2_b IS
   PACKAGE linked_list_b IS NEW linked_list ( abstract_b );
   TYPE record_b IS
      RECORD
         xxx: linked_list_b.list;
      END RECORD;
   -- list of other implementaiton details
END my_package_2_b;

Hope this helps.

Regards,
Chris

--
Full-Name:  Christopher J. Henrich
UUCP:       ...!hjuxa!petsd!cjh
US Mail:    MS 313; Concurrent Computer Corporation;
            106 Apple St; Tinton Falls, NJ 07724
Phone:      (201) 758-7288
Concurrent Computer Corporation is a Perkin-Elmer company.