Front page | perl.perl5.porters |
Postings from December 2007
On 23/12/2007, Nicholas Clark <nick@ccl4.org> wrote:
> On Sun, Dec 23, 2007 at 12:20:47PM +0100, demerphq wrote:
> > On 23/12/2007, Chris Dolan <chris@chrisdolan.net> wrote:
>
> > > If this patch does go in, we'll probably adapt Perl::Critic to know
> > > about this special case, and I'll probably go through all of my CPAN
> > > code to remove the extraneous modifiers, and I'll forget about this
> > > whole issue in a few months. But what a pain for so little gain...
> >
> > I dont see the problem. If you use the same modifiers everywhere there
> > will be no warning.
>
> This was what I was thinking too. But I wasn't sure sure, so I didn't e-mail.
>
> > The only place it will warn is when there is a mismatch between the
> > modifiers on a qr// and on the match processing the qr//.
> >
> > IOW:
> >
> > $qr=~/^foo/;
> > if (/$qr/m) {}
> >
> > If you never do stuff like this, for instance if you always write:
> >
> > $qr=~/^foo/m;
> > if (/$qr/m) {}
> >
> > there will be no warning.
>
> This check would work at runtime, so if $qr changes value it will only warn on
> a flag mismatch?
It will warn IFF the only content in the pattern is a $qr and the
modifiers the qr// was compiled with are different from the modifiers
on the actual match such that the discrepancy would change the
semantics of the match.
So assuming that Chris always uses /m the only time that Chris might
see warnings is if he wrote a procedure that accepts qr// objects from
outside his code and then executed them using the /m modifier. But
then he could disable the warning, or drop the /m modifier, or
whatever.
I really cant see this warning causing a lot of trouble.
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next