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

Yea and no. I have extended the parser so that methods (including traits) can access dynamic variables. The current version accepts code like:
    play1
        <Roles: #(Arrow12)>
        self displayLarge: '1'.
        Arrow12 play12.
where Arrow12 is a dynamic variable. It can be seen as an alias for an object,. The binding occurs at run time by a dictionary lookup; the dictionary is called a context and lives on the stack. The role traits are always executed in such a context. The roles appear at run time as context keys. 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.

Many programmers find it hard to think in terms of classes AND objects at the same time. I try to build an IDE that makes the bridge from class to object as short and intuitively simple as possible. (I also have to hide the fact that the context lives on the stack).

Cheers
--Trygve


On 16.05.2008 16:07, itsme213 wrote:

"Trygve Reenskaug" [hidden email] wrote in message

  

It was a major breakthrough when I realized that a role should be coded
as a trait, the trait defining what the object does in the context of a
structure of collaborating, role playing objects.
    

This mapping of role to trait is quite intuitively appealing.

However, since
- traits are applied statically, not dynamically
and
- trait callbacks to the object (required methods) are hardcoded in the 
trait definition itself with no way to rename (only alias)

Wouldn't it be quite difficult to handle the more general cases of dynamic 
roles, and of multiple roles of the same role type (e.g. I am a programmer 
on projects p1 and p2)?

In these casees would you revert to using separate role-objects? e.g. a 
Person class with a iVar that is a collection of role-like objects, one for 
"programmer-on-p1" and one for "programmer-on-p2"?

Curious - Sophie 





  

"Trygve Reenskaug" <[hidden email]> 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

On 17.05.2008 02:03, itsme213 wrote:

"Trygve Reenskaug" [hidden email] 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

"Trygve Reenskaug" <[hidden email]> wrote in message

> The short answer is yes, because the two executions of the same trait
> can have different bindings from roles to objects.

Sounds outstanding! I look forward to getting into this.

- Sophie