Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics
Id: 69294
Status: resolved
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: rjray [...] blackperl.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 1.116
Fixed in: (no value)



Subject: ProhibitLvalueSubstr references version->new() without use'ing version
I have a script built around Perl::Critic that recently (after upgrading P::C to 1.116) started reporting the following error: Couldn't require Perl::Critic::Policy::BuiltinFunctions::ProhibitLvalueSubstr : Can't locate object method "new" via package "version" (perhaps you forgot to load "version"?) at /usr/lib/perl5/site_perl/5.8.8/Perl/Critic/Policy/BuiltinFunctions/ProhibitLvalueSubstr.pm line 26. Funny thing is, on one machine it gives the error above, on a second machine with the same version of P::C, it works fine. Either way, the reality is that ProhibitLvalueSubstr.pm does not "use version", but tries to instantiate a version object. -- Randy J. Ray rjray@blackperl.com randy.j.ray@gmail.com
On Tue Jul 05 15:52:42 2011, RJRAY wrote: Show quoted text
> I have a script built around Perl::Critic that recently (after > upgrading > P::C to 1.116) started reporting the following error: > > Couldn't require > Perl::Critic::Policy::BuiltinFunctions::ProhibitLvalueSubstr : Can't > locate object method "new" via package "version" (perhaps you forgot > to > load "version"?) at >
/usr/lib/perl5/site_perl/5.8.8/Perl/Critic/Policy/BuiltinFunctions/ProhibitLvalueSubstr.pm Show quoted text
> line 26. > > Funny thing is, on one machine it gives the error above, on a second > machine with the same version of P::C, it works fine. Either way, the > reality is that ProhibitLvalueSubstr.pm does not "use version", but > tries to instantiate a version object.
Thank you for the report. This was fixed in SVN revison 4083, (in response to RT 68498) but unfortunately that only means it's OK in the code repository. We still need to make a distribution. No, I have no idea why it's only a problem sometimes. It will of course work providing ANY Perl::Critic module loads 'version', which is why it got out into the wild. I hypothesize that Module::Pluggable just traverses the directory, and it becomes a question of what order the files are in the directory. But that just pushes the question back to why the directories are in different orders, and I have no idea why that would be so either. Tom
Show quoted text
> I hypothesize that Module::Pluggable just > traverses the directory, and it becomes a question of what order the > files are in the directory. But that just pushes the question back to > why the directories are in different orders, and I have no idea why > that > would be so either.
If Module::Pluggable just reads directory contents directly, without sorting, then it would be dependent on the inode order of the files. That would explain why side-by-side machines could/would exhibit different behavior. -- Randy J. Ray rjray@blackperl.com randy.j.ray@gmail.com
This was fixed in Perl-Critic-1.117. Thanks for reporting it. -- Jeffrey Thalhammer Imaginative Software Systems www.imaginative-software.com