A long time ago ... Dan said:
Roles'll get thrown on individual variables and values, sure, but when I'm writing a class (Yes, I know, but lets suspend disbelief for a moment :) I'm not generally going to put a pre-existing role on a class--I'll just inherit from the darned thing. Roles, when working with whole classes, will be more a declaration of interface than an importation of implementation. (That, I suppose, argues for two separate sets of syntax, one for runtime role aquisition and another for class definition, but I think I won't go there)
Sorry for reviving an old thread here, but I am new to the list and I wanted to comment on something Dan said here.
I have been working on a Perl 5 implementation of Traits, so I have been reading and thinking about them a lot lately. I have been basing much of my implementation and understanding of them off of this paper - http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi? query=Traits+the+Formal+Model, which is a more formal model of Traits than is described in either the initial traits paper or the one that discusses the Smalltalk Collection refactoring. One thing that I noticed was that the authors seem to not intend Traits to be thought of as being like Classes. As a matter of fact they distinguish Traits from Classes in their "Trait Language" (contained in the above paper). So the idea of just being able to "inherit the darned thing", would not work as a Trait is not a Class. Traits too are "flattened" into the class that uses them, so there is no true inheritance there. Traits themselves can be composed out of other traits though, but again the flattening happens and no true inheritance exists.
But of course, Traits aren't Roles, and being new to the list, I am not sure how much different they are to be. I will have to read back a ways and see what was said. But I just wanted to put my 2 cents in here.
- steve
