On Tue, Aug 08, 2006 at 12:00:03 +0000, Luke Palmer wrote: > The difference, though, is that this ambiguity error happens at > call-time, whereas most ambiguity errors happen at composition time.
As I saw it it's not really a role, it's more of a no-op coercion.
Instead of actually writing an adaptor class, you could get off
cheaply if the adaptor doesn't need any more instance data than is
already provided by the "main" object.
So yes, it's runtime, but it doesn't matter.
> 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.
Hmm... Are the 'adapts' things actual class bodies? Like an inner
class?
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgpt3fkl5vE9I.pgp
Description: PGP signature
