develooper Front page | perl.perl5.porters | Postings from December 2007

Re: Changes in m//m in 5.10

Thread Previous | Thread Next
December 23, 2007 03:52
Re: Changes in m//m in 5.10
Message ID:
On 23/12/2007, Nicholas Clark <> wrote:
> On Sun, Dec 23, 2007 at 12:20:47PM +0100, demerphq wrote:
> > On 23/12/2007, Chris Dolan <> 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

I really cant see this warning causing a lot of trouble.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About