RolePlayers and Roles (was: PIE)

Sam Adams ssadams at us.ibm.com
Mon Feb 25 13:13:07 UTC 2002


Alan,
I agree with the need for "soft typing".  That's what we ended up doing at
KSC in the still-born CoDesign environment.  The approach we used was to
provide metadata for each method that provided a parsable signature
indicating the expectations for arguments and return values.  We manually
added these to the enitre VOS2 Digitalk environment and had a browser that
supported signature editing as well as stoplight metrics if a signature
agreed with the users code or not.  With this foundation Steve Burbeck
built a debugger capable of simulating Smalltalk execution using signatures
to produce the soft types, we called them qualifications, for  returned
objects.  It worked great and another version was done inside IBM for
Visualage which is still available.

If we had this kind of metadata for method running live (as ours did), the
message passing system would know  ahead of time that the signature of a
method had changed, even when the selector hadn't.  With qualifers, you
could also tell if the new returned objects could still function in the
calling method, all without running the code.

The signature and qualifier language paper has been posted to the list
before, but I can find a copy if there is interest.

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



                                                                                                                                              
                      Alan Kay                                                                                                                
                      <Alan.Kay at squeakland.org>               To:       squeak-dev at lists.squeakfoundation.org                                 
                      Sent by:                                cc:                                                                             
                      squeak-dev-admin at lists.squeakfou        Subject:  Re: RolePlayers and Roles (was: PIE)                                  
                      ndation.org                                                                                                             
                                                                                                                                              
                                                                                                                                              
                      02/25/02 09:46 AM                                                                                                       
                      Please respond to squeak-dev                                                                                            
                                                                                                                                              
                                                                                                                                              



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


--







More information about the Squeak-dev mailing list