Re: [squeak-dev] Re: Re: Unload Traits script (response to edgar)

On 17.05.2008 02:03, itsme213 wrote:

"Trygve Reenskaug" trygver@... wrote in message

  

This means that the same object can play several roles at
the same time by simply being bound to several keys. Conversely, the
same role can simultaneously  be played by different objects since there
can be several contexts on the stack at the same time.
    

Sounds good.

But can one object play the role Programmer on project 1, and Programmer on 
project 2, at the same time (i.e. the lifetimes of those 2 roles in that 
object overlap) using the same Programmer trait?

Cheers
- Sophie
  

The short answer is yes, because the two executions of the same trait can have different bindings from roles to objects. I'm sure there is a simple way to explain why this is true, but I have ended up with much more detail than is actually needed.

My BabyIDE hides this detail so that the programmer can focus on the static code and never think about the stack. Programming shall be simpler, not harder, when using roles as well as the traditional classes. But here are the details because I cannot make myself delete them once I have written them:

It may be misleading to think of traits in isolation here. A role always occurs in the context of a structure of objects that interact in order to achieve some common purpose such as a use case. Each participating object plays a particular role in the interaction. The role represents the responsibility of the object in the context of the interaction. The role also names the object so that we can refer to it in our code, postponing the name->object binding until the interaction is actually being executed. Finally, it includes the methods that describe how the object shall behave when playing its role in the interaction.

A role may be played by any object that behaves properly. Therefore, we do not need to consider the actual class when writing the code for the role. We merely reference the object by its role name. 

I have doctored the parser so that a role name in the code is inlined into a context dictionary lookup. In the following example, the role Shape1 is implemented by a trait also called Shape1. The trait defines one or more methods that describe the behavior of any object that is playing the role. Here's one such method:
    Shape1>>play2
        <Roles: #(Arrow23)>
        self displayLarge: '2'.
        Arrow23 play23.

If  I decompile this, I see the context dictionary lookup explicitly:

    Shape1>>play2
        <Roles: #(#Arrow23)>
        self displayLarge: '2'.
        (Baby4Collaboration playerForRole: #Arrow23) play23.

playerForRole: is a class method in Baby4Collaboration. It searches down the stack to find the first context that binds #Arrow23 to an object. That object must be instance of a class that uses the trait Shape1.

A context is put on the stack at the start of the execution of an interaction, so it  only exists for the duration of this execution. I assume that project 1 and project 2 in your example above are two different executions that may overlap.

If we are thinking in terms of single-threaded execution, project 1 will be put on the stack and the project 1 bindings will be the current bindings. If we then enter project 2, the project 2 bindings will be current until the completion of project 2. The project 2 context will be popped off the stack, and the project 1 bindings will be current until project 1 is also completed. So both bindings can exist at the same time, but only one can be active in a single-threaded execution.

If we are thinking in terms of multi-threaded execution, the executions will have different stacks. So, the project 1 and project 2 contexts will be on different stacks and the role/trait methods will will bind role names to different objects since they are executed in different contexts. And both contexts are active simultaneously.

Cheers
--Trygve