I can't do that for the exact reason that I want to use named capture buffers. The regular expression is very complicated. It's basically of the form:
$re = qr/($re1|$re2|...|$reN)/;
where each of the pieces may match a valid time. But some may match a partial time (perhaps only hours and minutes), some may match a 24-hour time and others may include an AM/PM string, some may include timezone information, and because there are so many ways to express times, some of them may even have the order of the fields changed, so I wouldn't want to depend on the order of the matches always being ($h,$mn,$s).
So, using numbered matches, I could do something like:
foreach $re ($re1,$re2,...) {
($h,$mn,$s) = $string =~ $re;
last if ($h,$mn,$s)
}
except that that won't work because I'm relying on the order of matches (and assuming that there will always be an $h match, etc).
With named capture buffers, I can do this so elegantly. I define each regexp, name the capture buffers (in whatever order they come in) and the named buffer will contain all the ones that actually matched. Maintaining the complicated regexps in Date::Manip is about 100 times easier now!
| [reply] |
OKay, I can see what is driving your requirements. One possibility that might prove a little quicker is Alternative-capture-group-numbering*, which allows you to re-use capture numbering within different match alternatives.
The example given at the reference above is very pertinent to your use. It might at least be worth benchmarking.
*Unfortunately #anchors no longer seem to work at perldoc since they added that annoying moving menu :(
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
I'm using a dynamic width style override for perldoc, and the anchors work fine for me. (It also rearranges the sidebars and locks the floating bar to the top and generally squeezes out the unneeded fluff.) Your anchored link, for example, looks great to me
How to make perldoc.perl.org resizable too!
| [reply] |
Good suggestion. I'm aware of them... I read up on them as I was learning about named buffers, but I quickly skipped them to the much nicer named buffers. However, I did NOT try to implement them. I'll spend some time looking at them as a possible compromise between the two.
| [reply] |
If the optimisation is that important, couldn't you just ‘pre-compile’ by doing the counting (laboriously and by hand, if necessary) once and taking into account the various possibilities? It's less elegant, but it seems that speed rather than elegance is your primary driver (with elegance a secondary bonus).
$re = qr/(?<h1>...)(?<m1>...)(?<s1>...)|(?<h2>...)(?<m2>...)(?<s2>...)
+/;
$string =~ $re;
( $h, $m, $s ) = ( $1 || $4, $2 || $5, $3 || $6 );
| [reply]
[d/l] |
I'm more interested in elegance (and maintainability) than in the optimization. I rewrote all of the regexps in Date::Manip to use named buffers, and I'm not interested in going back to numbered buffers.
As an example, in one place in Date::Manip, I match a set of related regular expressions that match various date strings, and there are 23 different possibilities containing 65 different matches between them (NOT all in the same order), so manually counting all of the match positions, while doable, basically renders that code static and unmaintainable... a simple change to the regexps leads to a very tedious and error-prone piece of work to maintain it. I think that's the worse case... but there are a several other cases that are almost as bad.
That said, I want as much optimization as I can, within that constraint, and that's the basis for my question.
| [reply] |