Re: Roles are fundamentally broken?
I opened https://github.com/rakudo/rakudo/issues/2662 - but keyword ought to be associative https://github.com/rakudo/rakudo/issues/2663 - Fix Role private methods documentation, implementation -y
Re: Roles are fundamentally broken?
Have you tried printing ^mro of $best_friend? You would be surprised! Instead,
try compiling the following:
role R1 {
method !priv { say "R1::priv" }
}
role R2 {
method !priv { say "R2::priv" }
}
class Foo does R1 does R2 {
}
Oops And this I consider a major problem. I as a developer must not care
about private methods of third-party modules. But I would have to! That's why I
want roles to be something more than mere collection of entitites mixed into a
class.
> On Jan 30, 2019, at 1:47 AM, yary wrote:
>
> > 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 () {
> say "tais toi!";
> self.
> self!bow;
> }
>
> method !bow {
> say ""
> }
> }
>
>
> # Learn to play
> role Violinist {
> method fiddle {
> say "got sheet music, got rosin...";
> self!bow;
> }
>
> method !bow {
> say ""
> }
> }
>
>
> # cute and playful
> class Puppy {
> method greet {
>say "";
>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
>
> Bow wow wow!
> tais toi!
> got sheet music, got rosin...
>
>
>
> I'm very happy with that behavior. Would like it to be documented.
>
> (And, I'll add comments to your bug tickets now)
> -y
Best regards,
Vadim Belman
Re: filever.exe sub?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 A quick search yields me the program `pev`: http://pev.sourceforge.net/doc/manual/en_us/ Maybe this can help you out. If it performs the tasks you need it to perform, you could browse the source code and rewrite it into a Perl 6 project :) On Tue, 29 Jan 2019 21:57:28 -0800 ToddAndMargo via perl6-users wrote: > On 1/29/19 9:53 PM, ToddAndMargo via perl6-users wrote: > > Hi All, > > > > Windows provides a utility called filever.exe which will > > tell you the revision of and exe file. (You can also see this > > through the gui with properties). > > > > Currently I run filever.exe through Wine. It is cumbersome, > > especially since Wine floods STDERR. I work around it. > > > > Do we have a module for the file's version? If so, does > > it run in Linux? > > > > If not, does anyone know where the version information is > > stored in and .exe file so I can write one myself? > > > > Many thanks, > > -T > > Sorry. I keep using "and" instead of "an". Stinkin' typos. -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEtvaXdC78r18jzlHVAx1lkC6ECCEFAlxRuQMACgkQAx1lkC6E CCFC0gf/T4if9Gt3YUcTLWDobaWlvo6ewwsxcXJQlD7u8O46ImcAlVSyJRBjAkkN 5Lbatc/UleyzIk3qJmWSCgJyzEV0ZgakdcBAtumB9mrxZrg0cPWBNblDDo+pnSJA qjpkB690KqlUNuZmBhfp/Xh6E2wWi7PhoDWlYtrJ/1j+AF8iGonuV1/93cXXw1fO MCs+S9Rn41hb4SqTJShaELLxzR39UmdE3/f0istOFOq3bsaE/WOxxJ4ovccuIEJw /xdS7tOLHMQoTSQTH/xjx7BdyUmCTfspsEmqqfoh2NgD+IOuo4lt3Ns3INPFfNfO 4EwZc2IgWaFrJPe1lf2Hmag/0pPoyg== =TCki -END PGP SIGNATURE-
Re: Roles are fundamentally broken?
El mié., 30 ene. 2019 a las 7:48, yary () 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 () {
> say "tais toi!";
> self.
> self!bow;
> }
>
> method !bow {
> say ""
> }
> }
>
>
> # Learn to play
> role Violinist {
> method fiddle {
> say "got sheet music, got rosin...";
> self!bow;
> }
>
> method !bow {
> say ""
> }
> }
>
>
> # cute and playful
> class Puppy {
> method greet {
>say "";
>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
> **
> *Bow wow wow!*
> *tais toi!*
> *got sheet music, got rosin...*
> **
> **
>
> I'm very happy with that behavior. Would like it to be documented.
>
Can you please create a documentation issue for that?
JJ
