in reply to Re: Pattern Matching Query
in thread Pattern Matching Query

Good implementation, I consider it the best of those posted because it explicitly matches only those conditions that were given in the example as you say, as opposed to some of the others which match considerably more. With poker, you don't really want to screw up :)

I offer a slight modification: 

if (join('','a'..'m') =~ qr/$sv/ && $sv =~/^[a-m]{5}$/){
    print "Matched\n";
}

[download]

Which just means you don't need to specify the whole of the range, just the start and end, you could sub it like this: 

sub match_range {
    my ($string, $start, $end, $length) = @_;
    if (join('',$start .. $end) !~ qr/$string/) { return 0; }
    if ($string !~ /^[${start}-${end}]{$length}$/) { return 0; }
    return 1;
}

[download]

Replies are listed 'Best First'.
Re^2: Pattern Matching Query
by Aristotle (Chancellor) on Sep 18, 2002 at 07:22 UTC
    Nice, but since boolean operators shortcircuit anyway (ie the right operand of && won't even be evaluated if the left one is already false), you just added a lot of blocks for no gain. Also, return 0 is a bad meme, if you want to return false then just return (which is equivalent to return wantarray ? () : undef). 
    sub match_range {
    my ($string, $start, $end, $length) = @_;
    my $range = join '', $start .. $end;
    return
        $range =~ /$string/
        && $string =~ /^[$range]{$length}$/;
}

    [download]
    Just a bit of nitpickery.. :-)

    Makeshifts last the longest.

[reply]
[d/l]
      Actually what I did was introduce two guard clauses. I am aware that it was correct in either fashion, it is my preference to have drop-through rules of the manner displayed previously. I also prefer explicit "false" return, and if there was some way I could say "return false" and get the same effect as just "return" I'd be using it :) undef isn't a bad concept tho.

      Those are simply elements of my style however, the reasoning behind guard clauses is obvious in larger functions, in this case it is superfluous but assuming a reasonably efficient action on the part of the interpreter I see no likely efficiency loss, so the consistency rule applies :)

      The re-use of the $range var is nice however.

[reply]

        The problem with return 0 is that it's true - in list context. The only false list is the empty list and yours has one element.

        Your approach separates a single statement into three distinct ones and will execute that way too. There is in fact loss of efficiency associated with using blocks there. The interpreter cannot optimize anything in the first place, and if you meant compiler optimization, it won't salvage any efficiency because it's rather rudimentary even if it has a few clever tricks for some highly specific cases.

        And not only does it execute that way, it has to be read like that too, with far more brackets and keywords around to grok. Compare the plain-English translations:

        if an assertion fails abort the function, if a second assertion fails abort the function, if still here then return true
        vs
        return the combined success of assertion one and two

        You tell me which one is more fluidly readable. Remember - source code is only coincidentally machine interpretable, its main purpose is to be read by a programmer.

        Makeshifts last the longest.

[reply]

In Section Seekers of Perl Wisdom