My collaboration is a name space for roles. An object can play different 
roles in different collaborations, but I cannot have the same role in 
different collaborations since the role is an attribute of the 
collaboration. Roles in different collaborations can thus have the same 
name without conflict.

Anther question is the name space for traits/methods, and there may be 
potential conflicts here.
 I am trying to get some kind of Browser with Traits, hoping that 
experiments will clarify what I am talking about.

Your example, "I am a Programmer in project p1, and also in  project p2. 
" is unclear to me because I cannot see how it relates to system 
behavior. It could mean that p1 and p2 are instances of the same class 
and I do not see a problem. Alternatively, p1 and p2 could be instances 
of different classes with different features. In that case, the example 
sounds to me like part of a conceptual schema; i.e., a description of 
system state.

I use different paradigms for coding system state and system behavior. I 
code system state as an ensemble of classes with their attributes and 
associations. I code system behavior as a collaboration with its 
associated methods for each system operation (use case). Traits seem 
promising for coding system behavior as stateless methods within a 
collaboration.

Cheers
--Trygve

On 19.02.2008 19:29, itsme213 wrote:
> "Trygve Reenskaug" <trygver at ifi.uio.no> wrote in message
>
> btw, I get various errors loading BabySRE in Squeak 3.9.
>
>   
>> My next step is to code the methods as Traits, thereby further loosening
>> the binding between role and object/class.
>>     
>
> I wonder how far Traits can help. An object can play the same role in two 
> different collaborations e.g. I am a Programmer in project p1, and also in 
> project p2. One would like to apply the same Programmer trait twice, with 
> the option of having separate (class-based) state for each of p1 and p2. I 
> don't think this is possible with Traits.
>
> Traits use unimplemented self-calls as "required methods" to (among other 
> things) access such state. However, you cannot parameterize these required 
> methods (you can rename provided methods, but not required methods which 
> would need some kind of automatic code generation/re-writing of intermediate 
> traits).
>
> I am hoping to get Damien's or Stephane's insights on this. 
> http://www.nabble.com/A-Traits-question-td15484148.html
>
> Do you think you will hit this limitation? Or does your intended usage avoid 
> this issue?
>
> Thanks!
>
> Sophie 
>
>
>
>
>
>   

-- 

Trygve Reenskaug       mailto: trygver at ifi.uio.no

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

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

Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080219/7a63b6ef/attachment.htm