Is method conflict of roles fatal? Is there the way to resolve?

[yuki-kimoto]

Is method conflict of roles fatal?

https://github.com/Ovid/Cor/blob/master/rfc/roles.md#83-example

Roles may consume other roles and classes may consume one or more roles. Any method name conflicts are fatal, if and only if the methods come from different namespaces.

role A :does(C) { method a () { ... } }
role B :does(C) { method b () { ... } }
role C          { method c () { ... } }

class SomeClass :does(A, B)   { ... }
Thus, in the above example, though A and B both pull in the c() method from role C, there is no conflict because it is the same method.

However, if SomeClass defined a c() method, there will be a conflict.

A fatal example:

role Breakable {
  method break () { ... }
}

role Breakdancer {
  method break () { ... }
}

class FragileDancer :does(Breakable, Breakdancer) {

}

This is maybe fatal. I want to know the way to resolve these.

Resolution of Moose

Is Moose resolution way used in Corinna?

https://metacpan.org/dist/Moose/view/lib/Moose/Manual/Roles.pod#METHOD-CONFLICTS

If a class composes multiple roles, and those roles have methods of the same name, we will have a conflict. In that case, the composing class is required to provide its own method of the same name.

package FragileDancer;
 
use Moose;
 
with 'Breakable', 'Breakdancer';
 
sub break { ... }

I rewrite the code using Corinna

role Breakable {
  method break () { ... }
}

role Breakdancer {
  method break () { ... }
}

# Compilation OK?
class FragileDancer :does(Breakable, Breakdancer) {
  method break () { ... }
}

[Ovid]

Is method conflict of roles fatal?

Yes.

This is maybe fatal. I want to know the way to resolve these.

Unfortunately, we never had agreement on the syntax for method exclusion, aliasing, or renaming. Thus, it's not in the Corinna spec, even though, as you point out, it's a needed features.

Instead, you'll need to do something like this:

role Breakable {
  method break () { ... }
}

role Breakdancer {
  method break () { ... }
}

class NastyDancerHack :does(Breakable) {
    ...
}

class NastyDancerHack2 :does(Breakdancer) {
    ...
}

class FragileDancer {
  field $nasty_hack  { NastyDancerHack->new };
  field $nasy_hack2 { NastyDancerHack2->new };

  # Internallly delegate to those feilds as needed
}

No, I don't like the above, either. Until such time that we have a clean syntax for this, we're stuck. If you have suggestions for a such a syntax, I'd love to hear them :)

[yuki-kimoto]

If you have suggestions for a such a syntax, I'd love to hear them :)

A suggestion.

If the consumer class has the same method of the role method, the compilation is OK.

And needed method is called by manual. This is the same as the behavior Java's default methods conflict.

role Breakable {
  method break () { ... }
}

role Breakdancer {
  method break () { ... }
}

# Compilation OK and call the needed method by manual
class FragileDancer :does(Breakable, Breakdancer) {
  method break () { $self->Breakdancer::break(); }
}