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-30 18:12:55 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!network.ucsd.edu!mbk
From: mbk@inls1.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.ada,comp.object,comp.lang.c++
Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG)
Followup-To: comp.lang.ada,comp.object,comp.lang.c++
Date: 30 Sep 1994 22:46:03 GMT
Organization: Institute For Nonlinear Science, UCSD
Message-ID: <36i4fb$hsn@network.ucsd.edu>
References: <1994Sep29.133526.2134@swlvx2.msd.ray.com>
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: TIN [version 1.1 PL8]
Xref: bga.com comp.lang.ada:6346 comp.object:6939 comp.lang.c++:31160
Date: 1994-09-30T22:46:03+00:00
List-Id: <comp.lang.ada>

John Volan (jgv@swl.msd.ray.com) wrote:
: 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.


How about this kind solution?  I'm going to have to write in ersatz
Eiffel/Sather:

class TWO_WAY_RELATION{T1,T2} is
      private map_1_to_2:MAP{T1,T2}; -- MAP{T1,T2} is a hash table
			             -- data structure that finds T2's given
				     -- T1's as keys.
      private map_2_to_1:MAP{T2,T1};

      create is
	map_1_to_2 := #MAP{T1,T2};
	map_2_to_1 := #MAP{T1,T2}; end;

      add_pair(x:T1,y:T2) is
	 map_1_to_2.insert(x,y);
	 map_2_to_1.insert(y,x);
      end;

      find_one_given_two(y:T2):T1 is
	return map_2_to_1.find(y); end;

      find_one_given_two(x:T1):T2 is
	return map_1_to_2.find(x); end;

end; -- class TWO_WAY_RELATION

class EMPLOYEE is
	private shared mapper:TWO_WAY_RELATION{EMPLOYEE,OFFICE};
		-- shared so all instances access the same object

	find_my_office : OFFICE is
		mapper.find_two_given_one(self); end;

	set_my_office(o:OFFICE) is
		mapper.add_pair(self,o); end;

end; -- EMPLOYEE

class OFFICE is
	private shared mapper:TWO_WAY_RELATION{EMPLOYEE,OFFICE}
		-- shared so all instances access the same object

	find_my_employee : OFFICE is
		mapper.find_one_given_two(self); end;

	set_my_employee(e:EMPLOYEE) is
		mapper.add_pair(e,self); end;
end; -- OFFICE

---

Now, both Office and Employee present interfaces that can find
and set each one's counterpart.  Neither knows how to do this
except through the 'mapper' object, which presents a clean interface
for managing pairs.

Comments?

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".