« Return to Thread: [squeak-dev] Unload Traits script (response to edgar)

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

by Trygve Reenskaug :: Rate this Message:

Reply to Author | View in Thread

Some parts of this message have been removed. Learn more about Nabble's security policy.
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" trygver@... 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       mailto: trygver@...

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway



 « Return to Thread: [squeak-dev] Unload Traits script (response to edgar)

LightInTheBox - Buy quality products at wholesale price!