From @japhb

Since Roles compose their private methods into a Class (and thus Roles can
see each other's private methods), a Role ought to be able to require that
some other Role (or the Class) supply a particular private method, just as
they can for public methods.

See http://irclog.perlgeek.de/perl6/2015-07-11#i_10881271 :

19​:12 japhb m​: role A { method !foo { say "success!" } }; role B { method
!foo { ... }; method bar { self!foo } }; class C does A does B { };
C.new.bar();
19​:12 camelia rakudo-moar 58a5ed​: OUTPUT«===SORRY!===␤Private method 'foo'
must be resolved by class C because it exists in multiple roles (B, A)␤»
19​:12 japhb Is there any reason that one of the two above can't be made to
work?
19​:12 (Personally I think the last one should DWIM.)
19​:13 masak japhb​: I guess it comes down to how private methods from a role
compose into a class.

And then http://irclog.perlgeek.de/perl6/2015-07-13#i_10886690 :

12​:17 yoleaux 11 Jul 2015 21​:02Z <japhb> jnthn​: What are your thoughts on
http://irclog.perlgeek.de/p​erl6/2015-07-11#i_10881267 and
http://irclog.perlgeek.de/p​erl6/2015-07-11#i_10881334 ? Having no good
resolution kinda gets in the way of a nice refactoring (for now, I'm
copying the required private methods into each role that would want to
consume them, and then changing the names to not collide between the roles
which is ... blech.)
[...]
12​:19 jnthn .tell japhb I think the one at
http://irclog.perlgeek.de/p​erl6/2015-07-11#i_10881271
should indeed DWYM; feel free to file a ticket on that

From @moritz

Hi,

On Mon Jul 13 08​:30​:23 2015, gjb@​google.com wrote​:

Since Roles compose their private methods into a Class (and thus Roles can
see each other's private methods), a Role ought to be able to require that
some other Role (or the Class) supply a particular private method, just as
they can for public methods.

See http://irclog.perlgeek.de/perl6/2015-07-11#i_10881271 :

19​:12 japhb m​: role A { method !foo { say "success!" } }; role B { method
!foo { ... }; method bar { self!foo } }; class C does A does B { };
C.new.bar();
19​:12 camelia rakudo-moar 58a5ed​: OUTPUT«===SORRY!===␤Private method 'foo'
must be resolved by class C because it exists in multiple roles (B, A)␤»
19​:12 japhb Is there any reason that one of the two above can't be made to
work?
19​:12 (Personally I think the last one should DWIM.)
19​:13 masak japhb​: I guess it comes down to how private methods from a role
compose into a class.

And then http://irclog.perlgeek.de/perl6/2015-07-13#i_10886690 :

12​:17 yoleaux 11 Jul 2015 21​:02Z <japhb> jnthn​: What are your thoughts on
http://irclog.perlgeek.de/p​erl6/2015-07-11#i_10881267 and
http://irclog.perlgeek.de/p​erl6/2015-07-11#i_10881334 ? Having no good
resolution kinda gets in the way of a nice refactoring (for now, I'm
copying the required private methods into each role that would want to
consume them, and then changing the names to not collide between the roles
which is ... blech.)
[...]
12​:19 jnthn .tell japhb I think the one at
http://irclog.perlgeek.de/p​erl6/2015-07-11#i_10881271
should indeed DWYM; feel free to file a ticket on that

Fixed with rakudo/rakudo@6c2ad869fc and test added with Raku/roast@2edb3c91da

This works now​:

role A { method !foo(A​:D​:) { say "success!" } };
role B { method !foo { ... } };
class C does B does A { method bar {self!foo } };

C.new.bar();

Putting method bar into role B does *not* work, it executes the stub code. But that is a separate bug (properly over-eager optimization), which I'll try to fix, and if I fail, I hope I'll remember to file a separate issue.

Cheers,
Moritz

The RT System itself - Status changed from 'new' to 'open'

@moritz - Status changed from 'open' to 'resolved'