On 10/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote: [snip] > It was the fact that at each stage of the game, we summarized the > defaults and requirements for each role, ignoring the internal makeup > (i.e., what roles were composed into it, etc.).
So, in theory, one should be able to ask any given role "What do you provide?" as well as "What do you require?". (I'm not saying that the syntax should be available, but that the information to answer those questions should be easily calculable.) One concern I have is that I would like to believe that a role is a "group of related behaviors that provides a functionality." So, if Foo does roleA and I as the user of Foo asks "Do you do roleA?" and it replies "Yes," then I can make some assumptions about Foo's functionality. Otherwise, this devolves into interfaces. Interfaces suck, especially given as they're limited to naming. Now, if we were to say that all roles, by default, provide multimethods, then conflicts only occur for methods that have identical dispatching semantics. At that point, it's truly a conflict and would need to be resolved by the composer (whether that's a role or a class). 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. Rob
