Problems? Is your data what you think it is? | |
PerlMonks |
Re: The 'g' modifier in compiled regexby ikegami (Patriarch) |
on Apr 09, 2007 at 05:27 UTC ( [id://608930]=note: print w/replies, xml ) | Need Help?? |
Basically, it boils down to: g affects the operation (match or substitution), not the regexp. There's going to be problems if you associate it with the regexp. Read on for some problems. xism options are toggles. Their absence signify the opposite of their presense. If g were an option, its absence would mean "don't loop". Given that g must apply to the entire match or substitute operation. It makes no sense for it to affect only a part of it, so
Only
There's another subbtle, but ugly problem. Consider
Also consider
A match in scalar context using g and one not using it are simply not interchangeable. If g were to be a modifier on compiled regexps, allowing compiled regexps to be used in a match operator in scalar context would severly weaken that code. Obviously, disallowing compiled regexp in a match in scalar context is not acceptable. So what's the solution? An operator that compiles a regexp for scalar context and one that compiles a regexp for list context? yuck! It's simpler to let the user handle g.
or
Finally, consider
Notice how the s doesn't affect the (?:...), only what's in it? That means $re = qr/.../g; @matches = /$re/; makes no sense since part of the regexp doesn't loop ((?:...)) and part of it does (...). Again, we'd need to do $re = qr/.../g; @matches = /$re/g;, gaining nothing.
In Section
Seekers of Perl Wisdom
|
|