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

Reply via email to