El mié., 30 ene. 2019 a las 7:48, yary (<not....@gmail.com>) escribió:
> > Yet, have a look at my example with private methods
>
> All of the bug reports, code excerts use regular (public) methods. Do you
> have code to share with !private_methods and/or submethods? I just made an
> example, will be at the end of this email
>
> > If accidentally two roles declare same private method – I either must
> reject using one of them or resolve the conflict manually ...
>
> The docs say what to do if two roles declare the same regular method. I
> would expect the same to hold for private methods, and submethods- the
> consuming class would need to define its own same-named submethod or
> private method, calling the whichever role routine(s) it needs.
>
> it sounds like you'd like to have a role be able to declare some routines
> which only other methods in the role can use- not the consuming class, or
> any other role. Turns out that private methods in roles do the trick!
>
> use v6;
>
> # Turn anything into a public entertainer
> role Diva {
> method captivate (&talent) {
> say "tais toi!";
> self.&talent;
> self!bow;
> }
>
> method !bow {
> say "<takes a bow>"
> }
> }
>
>
> # Learn to play
> role Violinist {
> method fiddle {
> say "got sheet music, got rosin...";
> self!bow;
> }
>
> method !bow {
> say "<world's most beautiful melodies>"
> }
> }
>
>
> # cute and playful
> class Puppy {
> method greet {
> say "<sniff>";
> self!bow;
> }
>
> method !bow {
> say "Bow wow wow!"
> }
> }
>
> my $best_friend=(Puppy.new but Violinist) but Diva;
> $best_friend.greet;
> $best_friend.captivate($best_friend.^lookup('fiddle'));
>
> says
> *<sniff>*
> *Bow wow wow!*
> *tais toi!*
> *got sheet music, got rosin...*
> *<world's most beautiful melodies>*
> *<takes a bow>*
>
> I'm very happy with that behavior. Would like it to be documented.
>
Can you please create a documentation issue for that?
JJ
