use Perl

• Something like this (Score:2)

  by Juerd (1796)

  my $country = uc $card->country || '';
  $country = ($country =~ /^$|GBR/ ? '' : "[$country]");

  Possibly ^GBR$.
  • Re: (Score:1)

    by Aristotle (5147)

    Yuck. Using a pattern match to test string equality is smelly.
    • Re: (Score:2)

      by Juerd (1796)

      I can think of two reasons.
      
      One is ugly syntax, which I find a silly argument. All Perl code is ugly, but elegance is more important than beauty. And I think this is very elegant.
      
      The other is that you can only have 2_501_710 such matches per second (on my PM 1,5 GHz laptop, the average of 50% matches and 50% non-matches), which can be a valid argument in some cases. But if performance is the issue here, the method call should go first: my laptop can do just 1_415_988 method calls per second, and that's on an
      • Re: (Score:1)

        by Aristotle (5147)

        I am honestly somewhat alarmed that you could only come up with straw men. How about “a regex match always has many more subtleties and edge/corner cases than straight string comparison”?

        As soon as I saw your code I wondered: “Did he mean ^GBR$ or was the omission of anchors deliberate?” And next: “Hmm, he uppercased it but there’s no /i – was that on purpose?”

        I prefer to minimise the number of speed bumps that a casual reader of the code has to pass.
        • Re: (Score:2)

          by Juerd (1796)

          As for the omission of anchors: probably a bad idea. I considered this and added a remark about it to the post. OTOH, I frequently have code like:

          $lang =~ /nl|en|de|eo/

          if I know $lang will always be 2 characters. Here, I didn't know, and should have used anchors.
          
          The case sensitivity has nothing to do with regexes. With $foo eq 'GBR' you can (should) ask yourself the same question: shouldn't uc($foo) eq 'GBR' be used instead? However this is somewhat irrelevant here, as the line just before the match, an
          • Re: (Score:1)

            by Aristotle (5147)

            I’m not advocating baby-talk code like that.

            Note that neither of the variants you suggest preserves undefs/zeroes. For that case, I gave a much simpler version that folds both conditions into a single ternary.

            I don’t see how putting two conditions inside a regex as alternation is abstraction. You don’t have two Perl expressions, but instead a regex with two match possibilities. The complexity hasn’t gone anywhere, it’s still there right in front of the reader’s eyes,
            • Re: (Score:2)

              by Juerd (1796)

              I am indeed assuming that a method called "country" will not return 0, and that undef is to be equal to "". The addition of square brackets, and the complete omission of the country indication when it's one specific value, tells me that this will be used in another string, meant for end users.
              
              The complexity is still there entirely, but written in a more compact way: there's only one character in between. This makes it easier --for me-- to notice that in practice, both conditions lead to the same thing.
              
              I don
              • Re:Something like this (Score:1)

                by Aristotle (5147) <pagaltzis@gmx.de> on 2007.06.19 17:48 (#55679) Homepage Journal

                OK, being alarmed is hyperbole... to an extent. This particular example does not warrant it, but on general principle I *would* be worried if the only reasons you could come up with for preferring string comparison over regexes are performance and ugly syntax.

                Compare:

                my $country = uc $card->country || '';
                $country = ($country =~ /^$|GBR/ ? '' : "[$country]");

                With:

                my $country = $card->country;
                $country = ( $country and $country ne 'gbr' ) ? uc "[$country]" : '';

                Regardless of how you turn it, I doubt many people will agree with you that the former is easier to read than the latter – there are more interdependencies to pick up on in the former. It has two boolean expressions rather than one, and the uc on one line ties toegether with the regex match on the other. (I honestly only just noticed that, even though you previously explicitly pointed it out.) In the latter, each of the parts does less.

                Btw, previously you wrote:

                OTOH, I frequently have code like $lang =~ /nl|en|de|eo/ if I know $lang will always be 2 characters.

                Yeah, this is preferrable over the non-regex version, I think (only barely, but it is), but once we have smartmatch, I would write it that way. (In Perl 6 I’d use a junction, since that reads even more nicely; which brings us full circle since it would look very much like your code.)

                Reply to This

                Parent