Skip Menu |

This queue is for tickets about the Role-Basic CPAN distribution.

Report information
The Basics
Id: 71162
Status: open
Priority: 0/
Queue: Role-Basic

People
Owner: Nobody in particular
Requestors: GAISSMAI [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Hi Ovid, thanks a lot for Role::Basic! Some years ago I was looking for such a 'Tiny' module for simple mixins when I was writing the Net::SNMP::Mixin modules. Anyway, I took Sub::Exporter, since Role::Basic wasn't coded yet :-( Recently I used Role::Basic for a new project and was excited! Anyway, I'm missing a method to declare private subs in a Role package, not exported to the class by 'with'. As usually, first I tried method names with an underscore '_' in front, like 'sub _private_sub { ... }', but Role::Basic doesn't respect this convention. The -excludes option for 'with' in the consuming class isn't enough. There should already be an option in the role package itself to hide the private sub from being exported since the consuming package should nothing know about _private methods. Best Regards Charly
On Thu Sep 22 12:12:43 2011, GAISSMAI wrote: Show quoted text
> Recently I used Role::Basic for a new project and was excited! > > Anyway, I'm missing a method to declare private subs in a Role package, > not exported to the class by 'with'. > > As usually, first I tried method names with an underscore '_' in front, > like 'sub _private_sub { ... }', but Role::Basic doesn't respect this > convention. > > The -excludes option for 'with' in the consuming class isn't enough.
Hi Charly, I think I should probably update the documentation. I deliberately did not include that because I thought that primarily you could just do this: my $private_method = sub { my $self = shift; # do something with $self return $self; } sub public_method { my $self = shift; $self->$private_method; # do more stuff return $self; } By having the private method be a lexical sub reference, it's truly private and also does not get exported. Does this do what you need? Cheers, Ovid
Show quoted text
> my $private_method = sub { > my $self = shift; > # do something with $self > return $self; > }
Oops. There should have been a trailing semi-colon after that closing curly brace. Cheers, Ovid
Subject: Role::Basic and private subroutines
Am Do 22. Sep 2011, 12:52:47, OVID schrieb: Show quoted text
> On Thu Sep 22 12:12:43 2011, GAISSMAI wrote: >
> > Recently I used Role::Basic for a new project and was excited! > > > > Anyway, I'm missing a method to declare private subs in a Role
> package,
> > not exported to the class by 'with'. > > > > As usually, first I tried method names with an underscore '_' in
> front,
> > like 'sub _private_sub { ... }', but Role::Basic doesn't respect
> this
> > convention. > > > > The -excludes option for 'with' in the consuming class isn't enough.
> > Hi Charly, > > I think I should probably update the documentation. I deliberately did > not include that > because I thought that primarily you could just do this: > > my $private_method = sub { > my $self = shift; > # do something with $self > return $self; > } >
Hi Ovid, sure I know this, but it's unconvenient and has a lot more implications, like tests (Pod::Coverage) and lot more tools not looking in lexical variables for subroutines. I would prefer an option in Role::Basic for subroutines not exported to the consuming class. Best Regards Charly
... Show quoted text
> > Hi Charly, > > > > I think I should probably update the documentation. I deliberately did > > not include that > > because I thought that primarily you could just do this: > > > > my $private_method = sub { > > my $self = shift; > > # do something with $self > > return $self; > > } > >
> > Hi Ovid, > > sure I know this, but it's unconvenient and has a lot more implications, > like tests (Pod::Coverage) and lot more tools not looking in lexical > variables for subroutines. > > I would prefer an option in Role::Basic for subroutines not exported to > the consuming class.
and I forgot: By using lexical sub references as private methods, you have to declare the lexical before using it it other methods. Normally I put my private subs at the end of the module and not in front of it. Best Regards Charly
Hi Charly, I think you raise some fine points. You could predeclare the private methods with: my ($method1, $method2 ); sub public_method1 { ... } sub public_method2 { ... } $method1 = sub { ... }; # and so on Though I strongly suspect this isn't an answer you want to hear :) Also, as a long-time testing advocate, I strongly recommend that you don't stress *too* much about code coverage as it's a will-o-the-wisp which can lead you astray. Keeping the private methods small and rely on good integration tests from the public interface and you'll be fine. Plus, you can then refactor the private methods to your heart's content, secure in the knowledge that your public interface -- the contract you have with consumers, still works. While what you suggest is a good idea, there are some significant issues with that approach. In short, Role::Basic would need to be "finished" to go the whole route of being explicit about the provide/requires relationship. Right now I have a new book contract and an eight month old baby and I simply don't think I'm going to have the time to do the major work needed to do this "right". My best suggestion (and I'm very sorry about this), is to fork the code: https://github.com/Ovid/Role-Basic And supply a patch. I'm happy to offer design advice/guidance and consider merging a change back in, so long as it maintains compatibility with Moose::Role. Cheers, Ovid
Am Fr 23. Sep 2011, 03:44:13, OVID schrieb: Show quoted text
> Hi Charly, > > I think you raise some fine points. You could predeclare the private > methods with: > > my ($method1, $method2 ); > > sub public_method1 { ... } > sub public_method2 { ... } > > $method1 = sub { ... }; > # and so on > > Though I strongly suspect this isn't an answer you want to hear :)
Hi Ovid, you guessed it, but it's free software and your answer is totally OK! Anyway, thanks a lot for Role::Basic! Best Regards Charly