Role::Basic tweaks and the future
I wanted to know if people wanted Role::Basic as a stepping stone for Moose or just for roles. The results of my question are in and every person who has commented on this blog or in my Twitter feed has said the same thing: just roles. They know where Moose is if they want it.
That said, I still want to minimize pain if people upgrade to Moose. That leaves me with three issues.
- Allow people to easily add getter/setter methods (gets around a limitation in Perl's OO)
- Probably add -alias and -excludes methods to requires
- Find out why Role::Basic is sometimes failing on 5.6.2
I need to contact the authors of those reports, but right now I'm suspicious of this code:
sub _sub_package {
my $package;
my $ok = eval {
my $stash = svref_2object(shift)->STASH;
if ( $stash && $stash->can('NAME') ) {
$package = $stash->NAME;
}
else {
$package = '';
}
1;
};
if ( not $ok ) {
warn "Could not determine calling package: $@";
}
return $package;
}
The svref_2object function is exported from the B module. I cloned Perl from github — yay! for git + github! — and started digging around. I found the following commit.
commit 7252851f9977dfc5c982b985eeabcb43c006d03e Author: Nicholas Clark <nick at ccl4> Date: Wed Sep 8 16:53:34 2004 +0000 backport B to work on 5.8.x, so that a single version of the source can be maintained, and ultimately dual-lifed on CPAN (the version conditional changes are actually surprisingly small)
This makes me suspicious that I shouldn't trust B modules prior to 5.8.x? Can anyone confirm this? I'm reluctant to slap a 5.8 dependency on the Role::Basic code if I don't need to (yes, I know the arguments about how old it is).
As an aside: I've removed the dependency on Test::Most. Role::Basic now has no non-core dependencies.
B works fine on 5.6, or, at least, your use of it is fine. The problem is here:
which fails because ->can("can") seems to always returns true under 5.6, even if the package doesn't really exist at all. I can see what you're trying to do there, but I can't off the top of my head see a better solution; perhaps looking for the package's stash entry in the parents' stash? (But that's really gross.)