http://qs321.pair.com?node_id=964381


in reply to Re: Common Perl Pitfalls
in thread Common Perl Pitfalls

I actually meant to say that one shouldn't use a scalar as a regex anyway. I meant to say that, even if your correct semantics didn't require the use of \Q and \E (i.e. you actually needed the metacharacters) then you're better off using the qr// operator instead of building your regex as a literal string.

Replies are listed 'Best First'.
Re^3: Common Perl Pitfalls
by JavaFan (Canon) on Apr 10, 2012 at 21:29 UTC
    Well, that's nice you want to say that, but can you back up your statement with an argument?

      Several, actually.
      For starters, I happen to believe it's better for readability. Another thing is, the regex modifiers "come with it". So you can include things like the 'x' modifier right along with the regex; if you're using a string as a regex, on the other hand, you have to remember which modifiers you need when you finally decide to use it in a match.
      Also, even though it doesn't show in this example, qr// is more efficient as (IIRC) it pre-compiles its regex before matching: i.e. you can build the regex once and use it several times. I use the qr// operator this way to make my regexes "modular".
      Anyway, you already know that I've been wrong about efficiency before :), so please correct me if you have a different say on the matter. I'm here to learn...

        For starters, I happen to believe it's better for readability.
        Hmmm. Is
        $pat = qr/PAT/;
        more readable than
        $pat = q/PAT/;
        or
        $pat = 'PAT';
        If so, what is it that makes it more readable? Of course, readability is a subjective matter.
        Another thing is, the regex modifiers "come with it". So you can include things like the 'x' modifier right along with the regex;
        $pat = '(?x:foo bar)'; # Works fine
        if you're using a string as a regex, on the other hand, you have to remember which modifiers you need when you finally decide to use it in a match.
        I don't know what you mean by that.
        Also, even though it doesn't show in this example, qr// is more efficient as (IIRC) it pre-compiles its regex before matching: i.e. you can build the regex once and use it several times.
        That's only useful if you want to use exactly the same pattern in different lines of your program.
        I use the qr// operator this way to make my regexes "modular".
        That's exactly why I don't use qr much.
        my $pat1 = 'PAT1'; my $pat2 = 'PAT2'; $str =~ /$pat1$pat2/;
        In the above code snippet, Perl only has to compile a single regexp. Contrast:
        my $pat1 = qr/PAT1/; my $pat2 = qr/PAT2/; $str =~ /$PAT1$PAT2/;
        Now Perl has to compile three patterns, and stringify two of them. I've created programs that created large patterns from qr constructs that were dog slow, because the final pattern was huge (stringifying qr constructs adds more parens, and adds (?abc-def:)) -- replacing qr with q sped up the program significantly. (Perl has gotten better since, yet, building larger patterns from smaller ones using qr snippets is still less efficient than using q).
        I'm here to learn...
        Writing a meditation titled Common Perl Pitfalls suggests otherwise.
          A reply falls below the community's threshold of quality. You may see it by logging in.