"Trygve Reenskaug" <trygver at ifi.uio.no> 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