Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.cis.ohio-state.edu!math.ohio-state.edu!uwm.edu!reuter.cse.ogi.edu!qiclab.scn.rain.com!gemstone.com!servio!servio!aland
From: aland@servio.slc.com (Alan Darlington)
Subject: Re: Role Objects
Message-ID: <1996Jul30.182628.19039@gemstone.com>
Sender: news@gemstone.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <4t1fu8$gls@blackice.winternet.com>
Date: Tue, 30 Jul 1996 18:26:28 GMT
Lines: 47

bhabeck@dwave.net (Bryan Habeck) writes:
> My colleague, Greg Plummer, asked me to submit this for him: 
> 
> This message is directed to Alan Lovejoy. You responded to a previous question 
> that I posted about simulating multiple inheritance in Smalltalk and pointed 
> out that types and roles need to be separated. First of all, thank you (and 
> all others who responded) for the response. It has helped us a great deal. I 
> now have a follow up question about roles. I am happy with my prototype, but 
> there is one aspect of it that remains a problem. Heres an example:
> - I have the following objects: Person, DirectorRole and OfficerRole.
> - DirectorRole responds to the message #companies.
> - OfficerRole responds to the message #companies.
> - Person can play the DirectorRole and the OfficerRole at the same time.
> - Part of my design is that the only object that can collaborate with a role 
> object is the object playing that role (what I call the actor object), in this 
> case aPerson. So if aPerson is playing aDirectorRole, to get the companies, 
> you would execute the code aPerson companies. The problem is that if aPerson 
> is playing aDirectorRole and anOfficerRole at the same time, aPerson 
> companies is ambiguous, since both aDirectorRole and anOfficerRole respond to 
> #companies. The current prototype will answer the companies of its first role 
> object that responds to #companies.
> 
> Some solutions:
> 1. aPerson could implement #directorCompanies and #officerCompanies. I dont 
> like this because it couples aPerson to its role objects and aPerson should 
> not be responsible for knowing these things.
<snip>

I personally would favor #1.  The problem with #companies is that it is
ambiguous.  It would probably be most sensible for it to respond with a
merged set of companies from all roles that respond to #companies.

In real life, a person obviously knows what roles he/she plays, so I
don't think you can justify trying to keep aPerson stupid.

Think what you would do if you were both a director and an officer of
multiple companies, and somebody asked you what company you worked for.
You would probably ask which role he/she meant.  Since this is beyond
the scope of most programs (although it could be done in Smalltalk if
you passed an intelligent argument to #companies: :-), I would go with
#directorCompanies and #officerCompanies if your application needs to
make this distinction.

  Cheers,
  Alan


