Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Questions concerning /o regex modifier

by Limbic~Region (Chancellor)
on Nov 29, 2006 at 15:45 UTC ( #586721=perlquestion: print w/ replies, xml ) Need Help??
Limbic~Region has asked for the wisdom of the Perl Monks concerning the following question:

All,
I am likely getting some of this wrong and I am sure some of the more knowledgeable monks will correct the inaccuracies. The question remains regardless.

The /o regex modifier is an old optimization before qr// existed. If you had a regex that needed variable interpolation before compiling but knew the variable would never change, you could use the /o modifier to only compile the regex once (/$regex/o). In fact, if you broke your promise and modified the variable, the regex still would not be recompiled leading to some potentially buggy code. See perlre for more information.

The qr// operator greatly improved things. See perlop for more details. In my opinion, this pretty much rended the need for /o moot. I am not the only one, diotalevi has /o is dead, long live qr//! to say on the matter as well as this.

Ok, I get it - backwards compatability and TIMTOWTDI. There is a lingering question. It is pointed out here that in newer versions, perl automatically detects when a variable is changed and only recompiles a regex when necessary. This is apparently not documented. I checked perldeltas from 5.6 to 5.9.4 though I may have missed it.

So why is this behavior not documented? Is there any reason not to deprecate /o? I am happy to perlbug a doc patch but I am certainly not the most qualified to do so.

Cheers - L~R

Comment on Questions concerning /o regex modifier
Re: Questions concerning /o regex modifier
by suaveant (Parson) on Nov 29, 2006 at 15:51 UTC
    Well... there is that rare and special occasion when the variable changes and you don't want the regex to change...

    Remember we are talking about backwards compatibility and not good coding practices when I say this :)

                    - Ant
                    - Some of my best work - (1 2 3)

      suaveant,
      Yes for extremely old versions that did not support qr// it was useful. My question regarding deprecation stands. In very old versions the deprecated warning won't appear but in newer versions where it is not necessary it will. Makes good sense to me.

      Cheers - L~R

        I could see deprecating it... especially since very little that gets deprecated ever actually goes away anyway. No old code would actually break but they would get warnings.

        I wonder how it is being handled in Perl6... maybe you just have to wait a bit.

                        - Ant
                        - Some of my best work - (1 2 3)

Re: Questions concerning /o regex modifier
by diotalevi (Canon) on Nov 29, 2006 at 18:00 UTC

    If you interpolate without /o, perl will always do the work of stringifying everything you gave it and concatenating it all into a single string. If the current string matches the last string then the compiled regexp from last time is re-used. This is an implementation detail and would need justification to get documented.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      diotalevi,
      Ok, but I am still don't understand when and why /o is useful. Would you be kind enough to fill in the blanks?
      • Use /o when _____
      • Use qr// when _____
      • Rely on /$regex/ implementation details when _____
      • Do not use /o when _____
      • Do not use qr// when _____
      • Do not rely on /$regex/ implementation details when _____

      Cheers - L~R

        Use /o when

        • writing for a perl 5.005 and less.
        • You are nano-optimizing to avoid the null operation of a pp_regcomp given a qr// object

        Use qr// when

        • writing for a perl 5.6 and greater.
        • You want the syntax affordance of being able to say qr/\s/ rather than "\\s" (assuming your interpolating into some larger expression)

        Rely on /$regex/ implementation details when

        • you've bothered to read the source and know exactly what it's doing

        Do not use /o when

        • writing for humans to read (because almost no one understands what /o does)
        • on perls 5.6 and greater
        • ever. It's just bad style now.

        Do not use qr// when

        • on perl 5.005 and lower
        • you're writing a sub expression that's going to be interpolated elsewhere and you care that the regexp compiler takes longer to compile strings like '(?-xism:...)' slower than '...'.

        Do not rely on /$regex/ implementation details when

        • you haven't read the source to pp_regcomp.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      In other words, /o is still more efficient than leaving it out?

      Also, it is a sign (a flag, if you will) to humans that the variables in this expression will not (and should not) change.

        It's not a signal to 99% of the humans that will read it because almost no one gets what /o does. There's just the "Oh! Optimized! Ok, it's more better n' good!"

        It is faster to avoid doing the concatenation and string comparison work than not but those are cheap operations. If you were optimizing for that then you could just as well pass in a qr// object.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      /o is motivated by performance concerns. Significantly reducing the whole motivation for the existence of /o in the first place warrants documenting such a change.

      - tye        

        That's qr// and it's documented.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://586721]
Approved by grep
Front-paged by grep
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2014-04-19 10:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (480 votes), past polls