Sam --

There is still the annoyance of having to fix up sender-side code. 
Another way to handle this might be to fully qualify all sends, but 
simply filter out showing the qualifications in the sender-side code 
unless a preference on the method is clicked. This way the 
sender-side code would really know what the programmer wanted to do 
with some object, and yet the method would look as clean as possible 
...

Cheers,

Alan

-------



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


--