To me, the distinguishing feature between the role and class concepts has always been that roles lack internal structure: you don't have to worry about any hierarchies of what went into creating the role; you just have to pay attention to what attributes and methods it will add to whatever class you compose it into.
If A and B have method foo, and AB does both A and B, then AB should have one of: A's version, B's version, its own version, a virtual "pass the buck" version, or no version at all; it shouldn't have a hierarchy of versions to pick from. If you compose AB into a class, but you don't want the version of foo that it brings to the table (or if AB went with the "pass the buck" option), then you should either override it with your own version or explicitly bring in another role that has the version that you want - be it A, B, or Q. If you want to deal with hierarchies of methods, deal with classes instead of roles. -- Jonathan "Dataweaver" Lang
