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: 1108a1,66253344eaef63db
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,66253344eaef63db
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-10-05 17:01:43 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!ihnp4.ucsd.edu!network.ucsd.edu!mbk
From: mbk@inls1.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.ada,comp.object
Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG)
Followup-To: comp.lang.ada,comp.object
Date: 5 Oct 1994 21:09:25 GMT
Organization: Institute For Nonlinear Science, UCSD
Message-ID: <36v4m5$paq@network.ucsd.edu>
References: <1994Oct4.160056.4243@swlvx2.msd.ray.com>
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: TIN [version 1.1 PL8]
Xref: bga.com comp.lang.ada:6515 comp.object:7072
Date: 1994-10-05T21:09:25+00:00
List-Id: <comp.lang.ada>

John Volan (jgv@swl.msd.ray.com) wrote:
: I guess the real philosophical issue that everything is hinging on
: here is: "Is a binary association *part* of the abstraction of each of
: the classes, or is it a *separate* abstraction of its own?"

: Adam Beneschan objected to other solutions that put the association
: structure in a common root package, on the grounds that nothing from
: the "real world" was being modeled by that.  I disagree with that, and
: agree with Magnus Kempe that in fact the association should be treated
: as a first-class abstraction of its own, in some fashion.

I think it's somewhat more than just a 'philosophical' issue.

If you have a "thing" managing the mutual couplings, you can
easily guarantee that

 employee(office(this_employee_object)) = this_employee_object.
 (and the reverse).

i.e. that you always maintain an invertible one-to-one relation.

I thought this was one of the original requirements.

If you have a 'thing' relating the two, you can put this
guarantee logic in one place, instead of having this fact be
implicitly relying upon the proper programming of the classes
to be related.

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