itsme213 wrote:
> "Andreas Raab" <andreas.raab at gmx.de> wrote in
>> Trygve Reenskaug wrote:
>>> A role is played by an object at run time. This object can be an instance 
>>> of any class that implements its trait. So the trait is tied to a 
>>> fundamental abstraction that is on the same level as the class.
>> Interesting. But aren't you describing interfaces?
> 
> The role itself is better compared to a variable than to an interface.

Do you mean something like (for example) the "bounds role" or the "fill 
role" for Morphs? If not, then I don't understand what roles mean in 
this context.

> The  corresponding trait can provide an interface definition, as well as an 
> implementation that refers to other related roles.

It can but if it's to provide the implementation you end up with 
complexity explosion again since the dependencies will be implemented by 
other traits, which will require even more traits etc. By the end of the 
day there will only be a handful of suitable compositions of traits that 
result in something usable (which is exactly what we've seen in other 
applications of traits) and these few compositions usually can be better 
expressed without traits.

The idea that having traits require other traits for their 
implementation leads to flexibility is flawed. Flexibility results from 
having abstract interfaces which allow (and sometimes require) the 
implementor of the interface to go only by the observable structure and 
not rely on anything that just happens to be part of the implementation. 
Traits have been constantly used the other way around by requiring the 
users of one trait also to pull in all the garbage that comes along with 
the implementation of that trait.

> I think Trygve figured 
> out a way to extend the compiler so that the method bodies (typically in 
> traits, I expect) can use distinguished "Role variables", which the compiler 
> translated into a dynamic lookup query.

That will be interesting to see. Although, I can't help but wonder: Why 
not simply bundle up these "role variables" and their corresponding 
behaviors and call 'em "object"? In which case you'd represent them by a 
class, having access to all the state in one place, being able to 
encapsulate its behavior etc.

Cheers,
   - Andreas