trygver at ifi.uio.no
Tue Feb 19 19:06:29 UTC 2008
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
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
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
> I am hoping to get Damien's or Stephane's insights on this.
> Do you think you will hit this limitation? Or does your intended usage avoid
> this issue?
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev