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

Re: Changes in m//m in 5.10

Thread Previous | Thread Next
From:
demerphq
Date:
December 23, 2007 03:23
Subject:
Re: Changes in m//m in 5.10
Message ID:
9b18b3110712230323t419b3802qfd3cf600da3e0b46@mail.gmail.com
On 23/12/2007, demerphq <demerphq@gmail.com> wrote:
> On 23/12/2007, Chris Dolan <chris@chrisdolan.net> wrote:
> > On Dec 22, 2007, at 8:35 AM, Ævar Arnfjörð Bjarmason wrote:
> >
> > > On Dec 21, 2007 12:08 PM, demerphq <demerphq@gmail.com> wrote:
> > >> No it wont actually. The warning would only be raised when the $qr
> > >> variable is the only thing in the pattern. The diagnostics should
> > >> read
> > >> (added an 'only'):
> > >>
> > >> +(W regexp) Your pattern contains only a variable containing a
> > >> precompiled
> > >> +regular expression pattern whose behavior will not be changed by the
> > >> +pattern modifiers provided.
> > >>
> > >> $qr=/^foo/;
> > >> $x=~/$qr/m; # warns;
> > >> $x=~/$qr|foo/m; #does not warn
> > >> $x=~/$qr/x;  # does not warn (/x doesnt change match semantics)
> > >
> > > In the current implementation yes, but we might potentially want to
> > > warn in the future on useless modifiers in general, eg:
> > >
> > > $x =~ /(?-msix:^foo)/msi;
> >
> > I would like to make a few points in opposition to this new warning.
> > Before I do so, I'd like to acknowledge that such a warning would
> > certainly be useful in alerting 5.8 -> 5.10 upgraders about the bug
> > fix.  And I appreciate the effort expended in minimizing the scope of
> > the warning.  But I think it's a readability loss overall, and when
> > 5.8 is passé, we'll still be stuck with it.
> >
> >   1) The Perl Best Practices book recommends putting /m on all
> > regexes for consistency and readability.  In that paradigm, '^' and
> > '$' always mean start/end-of-line and never start/end-of-string,
> > which lightens the reader's mental load.
> >   2) Perl::Critic has been recommending /m on all regexes since 0.13,
> > so lots of people have adopted this habit.
> >   3) People who adopted that habit were not bitten by this 5.8 ->
> > 5.10 behavior change.
> >   4) The new warning would mean that the above practice is now
> > officially discouraged, at least in terms of the absoluteness of the
> > practice.
> >   5) Authors (like me) with working 5.8 code will have to remove
> > harmless /m modifiers from various places just to get their code to
> > run quietly.
> >   6) While the modifier is indeed useless in 5.10, it's not at all
> > harmful or wasteful, unlike say sort in void context which wasted CPU.
> >
> > 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.
>
> 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.

BTW, i think that there will be better solutions to PBP type issues
coming soon. In particular its in the plans to be able to set default
modifiers on patterns. So to be PBP compliant youd say something like

use re::modifiers 'msx';

cheers,
yves

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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About