Re: Should I use v5.10 because of named groups?

[Fletch]

First a syntax nit: personally I don't find that regex any more readable than:

my( $type, $valid, $name, $comment ) = split( qr/:/, $_ );

In fact if you're explicitly wanting it in a hash I'd almost say go with something like this is still (IMHO) clearer:

my %val;
@val{ qw/ type valid name comment / } = split( qr/:/, $_ );

Granted you're doing a minimal amount of validation checking [01] on the first two fields, but (without more context on your data) that doesn't feel that compelling. If you were to keep it with your regex with the capture groups then I'd at the least suggest adding an /x and putting whitespace around the colons so it's not as visually . . . run together.

As to your question of using an explicit version: you can check the docs on feature what that turns on (specifically say, state, and the switch construct). Since named capture groups aren't toggled with that all you're getting is maybe bailing earlier in the (as you say) unlikely case you were ever run with an older perl. So . . . meh? That being said though I'm habitually using (say :) say and state so I typically use a much newer required version in what I write. Having that explicitly set regularly helps find problems (typically PATH is messed up and it's running under the ancient OS' /usr/bin/perl not the one it should be which would cause other things to blow up (missing CPAN modules etc.)).

[hrcerq]

I guess you're right, that regex isn't any more readable than the alternatives you propose. In fact, I've rewritten it to:

if (/^([01]):([01]):([^:]+):([^:]+)$/) {
    my ($type, $valid, $name, $coment) = ($1, $2, $3, $4);
    
    ...

I maintained the regex as I'm fairly sure I'll need to improve it later for more checks on the input.

[Marshall]

Just a nit, in case you didn't know, but you can do the $1,$2,$3,$4 assignment in the if statement:


if ( my ($type, $valid, $name, $coment) = 
     $_ =~ m/^([01]):([01]):([^:]+):([^:]+)$/ ){}

I don't think this makes much difference. I just have a coding preference to avoid $1, etc.
I made 2 source lines because of code line length limits here. In actual code, I'd probably just have one line.