----- Original Message -----
From: Sam Adams <ssadams at us.ibm.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, February 25, 2002 1:01 PM
Subject: Re: RolePlayers and Roles (was: PIE)


> I haven't read the PIE papers in a very long time, but I have done lots of
> thinking about roles and object modeling over the years, especially wrt
CRC
> modeling.  This thread prompted a design thought that I'll throw into the
> soup:
>
> The basic object was a RolePlayer and contained a collection of Roles,
> where each Role instance would have the state and behavior appropriate to
> its role (and know its player).  The issues that arise are how to deal
with
> shared state between roles (e.g. annualSalary in EmployeeRole could also
be
> annualIncome in TaxPayerRole), and how to deal with message handling
> priority (aka, which role dominates in a particular scenario, eg
> takeSickChildToDoctor in FatherRole vs attendImportantBusinessMeeting in
> AmbitiousEmployeeRole).  The shared state problem seems to call for
> valueholder-like reference objects that would be constructed and installed
> in each Role with overlapping state when the roles are installed in the
> RolePlayer.
>
> The switching issue could be handled as it is with persons, namely, if you
> have a request for someone where you assume no particular role bindings or
> conflicts, you simply send the message to the object.  If you want to make
> sure that a particular role behavior is invoked, then call out the role as
> in "as the father of my children I expect you to..." or "as an employee of
> this company you need to ...".
....

Hi everyone,

I would suggest to define a module "Office" to deal with one role and
another
"Home" to deal with another role. Within the module Office, the EmployeeRole
may
be defined. All messages to the Person within this module would only be
regarded as Employee.
A special actor called "OfficeSecretary" might deal with the messages from
"Home" to
"Office".  With messages like: "HeIsInAMeetingRightNow",
"HeWillBeRightOnThePhone" :-)

For me each module, would rather be an environment in which the seperate
roles are played out.
At "Home" there is no need for the other roles. But the FatherRole,
MotherRole, ChildRole, are all
acting with each other. In the case of an interruption, an object like a
Telephone, might take an object
into another environment where it will have a different role.
Interesting is that the code would be very small and readable within such an
environment-module.
Also these environments would work like a sandbox.
A good compiler would find out if an environment does not understand certain
messages or symbols.

In the case of object-oriented modelling, one would use design-patterns to
define the "interfaces"
for basic role-playing (like MVC). These are then extended to more complex
roles and patterns.

An object "ProgrammerRole" playing a certain role, would be inherited
from "EmployeeRole" and that again from "Person", but it also has a
inheritance line from "FatherRole".
In this case a multiple inheritance over more environments, single
inheritance per role / environment.
But because within a module there is only one role, the other inherited
roles are not important.
Problems are the objects internal data (attributes) that may differ per
role,
and the interrupt exceptions. They might be managed by other roles
(ObjectDataRole) and
(InterruptHandlerRole).

Conflicts with classic smalltalk code would occur when roles are mixed.
FatherRole>>Work would call "PutGarbageOutside" and/or "RepairBike".
EmployeeRole>>Work would call "WriteReport" and/or "AttendMeeting".
If the environments are not seperated this would never "work" of course.

Greetings,
    Dirk Wessels