Sam --

That's the general idea. To me, the main hitch that has to be solved 
well is to deal with the nasty possibility of invalidating 
assumptions (via additions to the object/class) that previously 
worked on the sender side.
      The main two such things in the system now -- deleting a method 
that is needed by some sender and changing a method that violates 
some sender's assumptions -- seem to be handled more or less OK, 
though occasionally there is a gotcha.
      But we didn't feel it was OK in the days when ST-72 provided 
extensible syntax on the fly to have sender side code be suddenly 
invalidated by some change in a receiver class that would cause the 
sender side expression to have a different parse and meaning (a soft 
typing system would have helped here).
      The current scheme in question can have some of these nasty 
side-effects. It seems that some form of soft typing might also help 
here -- in the sense that one of the virtues of typing can be to 
allow sender side assumptions to be made more clear and explicit both 
to human and machine readers of their code.

Cheers,

Alan

-------

At 7:01 AM -0500 2/25/02, Sam Adams wrote:
>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


--