On 8/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
My original idea was that this is again an ambiguity error - without
the helper function stating which role it's using it cannot dispatch
the "header" method at all, since it's in a role-conflicted state.
The difference, though, is that this ambiguity error happens at
call-time, whereas most ambiguity errors happen at composition time.
It strikes me that there is a happy medium.
class Mail::TheOneTrueWay {
has $.some_api adapts Mail::SomeAPI {
method header;
# this method has different semantics for
# each role. It would normally conflict.
}
has $.some_other_api adapts Mail::SomeOtherAPI {
method header;
}
method body; # this method is shared between the two roles
}
Which would pull all that multiple delegation bullshit in my earlier
post. Creating the class is just as easy, and using it involves
putting .some_api and .some_other_api in appropriate places like a
delegation interface. It's not quite as DWIMmy, but the class
doesn't do either role so errors will be caught quickly. It is also
annotation-agnostic.
Luke
