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: 67659
Status: open
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: rod.taylor [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.115
Fixed in: (no value)



Subject: Named Captures (ProhibitUnusedCapture)
Download (untitled) / with headers
text/plain 380b
The code snippet below violates RegularExpressions::ProhibitUnusedCapture. PerlTidy should understand named captures and possibly even encourage their use over unnamed (position) based captures. Capture via brackets (?<digit>\d+) has the same report. #!/usr/bin/env perl use v5.10.0; use strict; use warnings; if ( 'abc12def' =~ m/(?'digit'\d+)/xmisg ) { say $+{digit}; }
Download (untitled) / with headers
text/plain 861b
On Thu Apr 21 06:08:45 2011, rtaylor wrote: Show quoted text
> The code snippet below violates > RegularExpressions::ProhibitUnusedCapture. PerlTidy should understand > named captures and possibly even encourage their use over unnamed > (position) based captures. > > Capture via brackets (?<digit>\d+) has the same report. > > > #!/usr/bin/env perl > > use v5.10.0; > use strict; > use warnings; > > if ( 'abc12def' =~ m/(?'digit'\d+)/xmisg ) { > say $+{digit}; > }
Perl::Critic does understand named captures, and your code would still be flagged if you used numbered captures. What is causing the policy to complain is the presence of /g. What is it accomplishing here? Will your code work without it? The thing is, normally a /g only accomplishes something in the condition of a while() loop, where you actually iterate over all matches, or in a list assignment.
From: rod.taylor [...] gmail.com
On Thu Apr 21 14:49:33 2011, WYANT wrote: Show quoted text
> On Thu Apr 21 06:08:45 2011, rtaylor wrote:
> > The code snippet below violates > > RegularExpressions::ProhibitUnusedCapture. PerlTidy should understand > > named captures and possibly even encourage their use over unnamed > > (position) based captures. > > > > Capture via brackets (?<digit>\d+) has the same report. > > > > > > #!/usr/bin/env perl > > > > use v5.10.0; > > use strict; > > use warnings; > > > > if ( 'abc12def' =~ m/(?'digit'\d+)/xmisg ) { > > say $+{digit}; > > }
> > Perl::Critic does understand named captures, and your code would still > be flagged if you used numbered captures. > > What is causing the policy to complain is the presence of /g. What is it > accomplishing here? Will your code work without it?
Indeed. I can remove the /g and everything works okay. I had thought /g did something else (multiple matching versus single or first match) which is what it does in PostgreSQL. Perhaps the ProhibitUnusedCapture could have a "Remember, /g also creates a capture" type note. Thank-you for pointing me in the right direction.
Download (untitled) / with headers
text/plain 1.8k
On Fri Apr 22 21:13:04 2011, rtaylor wrote: Show quoted text
> On Thu Apr 21 14:49:33 2011, WYANT wrote:
> > On Thu Apr 21 06:08:45 2011, rtaylor wrote:
> > > The code snippet below violates > > > RegularExpressions::ProhibitUnusedCapture. PerlTidy should understand > > > named captures and possibly even encourage their use over unnamed > > > (position) based captures. > > > > > > Capture via brackets (?<digit>\d+) has the same report. > > > > > > > > > #!/usr/bin/env perl > > > > > > use v5.10.0; > > > use strict; > > > use warnings; > > > > > > if ( 'abc12def' =~ m/(?'digit'\d+)/xmisg ) { > > > say $+{digit}; > > > }
> > > > Perl::Critic does understand named captures, and your code would still > > be flagged if you used numbered captures. > > > > What is causing the policy to complain is the presence of /g. What is it > > accomplishing here? Will your code work without it?
> > Indeed. I can remove the /g and everything works okay. I had thought /g > did something else (multiple matching versus single or first match) > which is what it does in PostgreSQL. > > Perhaps the ProhibitUnusedCapture could have a "Remember, /g also > creates a capture" type note. > > Thank-you for pointing me in the right direction.
I don't know what /g does in PostgreSQL. In Perl it creates a multiple match, but you only get one match per iteration. So the code you exhibit does the same thing with and without the /g. If you really expected to get and process multiple matches, you would do something like while ( 'ab12cd34ef56' =~ m/ (?'digits' \d+ ) /sxmg ) { say $+{digits}; } Yes, there are some corner cases related to yours that this policy flags falsely, but the policy is already fairly complex, and I hesitate to make it more complex before the need is demonstrated. As a side note, the /i probably does nothing in your particular regular expression, since it matches no letters.
Subject: Re: [rt.cpan.org #67659] Named Captures (ProhibitUnusedCapture)
Date: Sat, 23 Apr 2011 08:07:46 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 319b
On Apr 22, 2011, at 10:10 PM, Tom Wyant via RT wrote: Show quoted text
> As a side note, the /i probably does nothing in your particular regular > expression, since it matches no letters.
Now there's a potential policy! Jeffrey Thalhammer Imaginative Software Systems vcard: http://www.imaginative-software.com/contact/jeff.vcf
Download (untitled) / with headers
text/plain 397b
On Sat Apr 23 11:07:57 2011, jeff@imaginative-software.com wrote: Show quoted text
> > On Apr 22, 2011, at 10:10 PM, Tom Wyant via RT wrote: >
> > As a side note, the /i probably does nothing in your particular regular > > expression, since it matches no letters.
> > Now there's a potential policy! >
And maybe not too hard to do, except for the existence of things like m/\N{GREEK SMALL LETTER OMEGA}/i.
Download (untitled) / with headers
text/plain 199b
Show quoted text
>What is causing the policy to complain is the presence of /g.
I think this might be the same issue as <https://rt.cpan.org/Public/Bug/Display.html?id=67256> where the programmer mistakenly used /g.
From: pagenyon [...] gmail.com
Download (untitled) / with headers
text/plain 780b
On Thu Apr 21 14:49:33 2011, WYANT wrote: Show quoted text
> On Thu Apr 21 06:08:45 2011, rtaylor wrote:
Show quoted text
> Perl::Critic does understand named captures, and your code would still > be flagged if you used numbered captures. > > What is causing the policy to complain is the presence of /g. What is it > accomplishing here? Will your code work without it?
so what's wrong with this example? my $s = 'stuff: "a b c"; more stuff: "a e f"'; if ($s =~ /^stuff: "(?<stuff>.*)"; more stuff: "(?<more>.*?)"$/ or $s =~ /^more stuff: "(?<mmore>.*)"; stuff: "(?<stuff>.*?)"$/) { my %stuff = map { $_ => 1 } split /\s+/, $+{stuff}; my %more = map { $_ => 1 } split /\s+/, $+{more}; } I also see the policy Variables::ProhibitPunctuationVars is triggered by $+{stuff}. Wonder if that's related.
From: pagenyon [...] gmail.com
Download (untitled) / with headers
text/plain 953b
On Thu Aug 29 18:38:23 2013, pagenyon wrote: Show quoted text
> On Thu Apr 21 14:49:33 2011, WYANT wrote:
> > On Thu Apr 21 06:08:45 2011, rtaylor wrote:
>
> > Perl::Critic does understand named captures, and your code would > > still > > be flagged if you used numbered captures. > > > > What is causing the policy to complain is the presence of /g. What is > > it > > accomplishing here? Will your code work without it?
> > so what's wrong with this example? > > my $s = 'stuff: "a b c"; more stuff: "a e f"'; > if ($s =~ /^stuff: "(?<stuff>.*)"; more stuff: "(?<more>.*?)"$/ or > $s =~ /^more stuff: "(?<mmore>.*)"; stuff: "(?<stuff>.*?)"$/) > { > my %stuff = map { $_ => 1 } split /\s+/, $+{stuff}; > my %more = map { $_ => 1 } split /\s+/, $+{more}; > } > > I also see the policy Variables::ProhibitPunctuationVars is triggered > by $+{stuff}. Wonder if that's related.
just noticed the typo: s/mmore/more/. but that still results in the warning.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.