RolePlayers and Roles (was: PIE)

Sam Adams ssadams at us.ibm.com
Mon Feb 25 12:01:52 UTC 2002


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

This could be implemented using a mix of composite and facade behavior
where both RolePlayer and Role had a common interface for handling
roleplayer-style  messages (ala composite) but where at anytime from the
perspective of a sender, one Role instance or another was acting as a
facade for the RolePlayer. So if the RolePlayer recieved a message, it
would delegate handling to the first understanding Role in its collection
using a default priority order.  If a Role recieved the message that it
understood, it would simply do it. But if it did not understand, it would
delegate to the RolePlayer.  Of course, a guard against infinite regress
would be in order.  If a sender wanted a particular Role facade or
perspective on an object, it could use something like the old conversion
protocols (asString asForm asByteArray) except the returned object would be
the appropriate Role facade (playingFather or playingAmbitiousEmployee).

The result would be a system where each object could present multiple faces
to its collaborators, and new roles (or subsets of
responsibilities/interfaces) could be added and removed dynamically.  Lots
of details to work out, but there's the basic idea.  I'll leave the
meta-roles, geno-roles, and pheno-roles for another time.   ;-)
Regards,
Sam

Sam S. Adams, IBM Distinguished Engineer, IBM Research
tie line 444-0736, outside 919-254-0736, email: ssadams at us.ibm.com
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>



                                                                                                                                              
                      Jecel Assumpcao Jr                                                                                                      
                      <jecel at merlintec.com>                   To:       squeak-dev at lists.squeakfoundation.org                                 
                      Sent by:                                cc:                                                                             
                      squeak-dev-admin at lists.squeakfou        Subject:  PIE (was: Getting rid of metaclasses)                                 
                      ndation.org                                                                                                             
                                                                                                                                              
                                                                                                                                              
                      02/24/02 01:53 PM                                                                                                       
                      Please respond to squeak-dev                                                                                            
                                                                                                                                              
                                                                                                                                              



On Sunday 24 February 2002 19:18, Alan Kay wrote:
>       Goldstein and Bobrow eventually found a very interesting way to
> implement these enriched objects: they used Smalltalk instances for
> each role/perspective. So a PIE object could be made from many
> Smalltalk objects.

I suppose they used a flat "perspective space", right? Some other
proposals allow role inheritance, but that easily becomes a big mess.

How do you know which perspective to use at any given time? How do you
switch between them?

Sorry about the questions, but there is essentially nothing online
about PIE. I am trying (http://www.merlintec.com:8080/software/8) to
come up with something similar.

-- Jecel







More information about the Squeak-dev mailing list