Rob Kinyon wrote: > Now, it's obvious why a class would have to resolve that conflict. I > would say that a role would have to resolve the conflict is that a > role should present a consistent API to the rest of the world. In > other words, I want to be able to depend on the fact that classA does > roleAB means something in terms of the functionality that classA > provides to me. I don't want it to be a glorified can() check. That > does no-one any good.
Well, yes and no. I like the ability for default behavior to be passed along through composition; OTOH, I don't want to be forced to require that role A's default behavior will appear in role AB. To me, that sort of thing is what classes and inheritance are for. That said, roles differ from interfaces in that roles _can_ have default behavior associated with them - whereas interfaces really are nothing more than glorified can() checks. Think of it this way: with inheritance, every class has to be aware of its full lineage, as family connections are very important. With composition, the only family connections that are at all important are that descendants look like their ancestors. -- Jonathan "Dataweaver" Lang
