On 10/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> 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.


Reply via email to