|Wed 1998-08-26 Philip Guenther <guenther(_at_)gac(_dot_)edu> list.procmail
| [jari wondered why the regexp was not abstracted]
|
| In my original exposition of that regexp, I showed how I built it up
| from the relevant syntax lines in rfc822. Indeed, at your request I
| then posted a variableful version with variables named after some of
| those syntactical categories.
Ouch :-) That hurts when I'm poking my own leg. I remember it now.
| It's not my fault if someone chooses the One Huge Regexp version.
I forgot that beatiful RFC abraction you wrote. It was pice of art.
Sorry about forgetting it.
| Rather, I agree with them with the following reasoning:
|
| 1) I'm not planning on "maintaining" that code, as the syntax for
| message-id will not, for practical reasons, ever change.
|
| 2) I some how doubt that anyone else will change that regexp more than
| trivially (e.g., negate it, make it start "^Resent-Message-ID:",
| change the line breaks).
|
| 3) If none of your other regexps use the categorical variables, and
| you're not changing the message-id regexp, then what's the point?
| The variablized version will be slower, and will clutter the
| environment of subprocesses.
|
| So, the only reason I can see to break it up would be if you have other
| uses for the subregexps. If you don't, don't do it.
I have been participating in so large projects that the only way to handle
or understand the code afterwards is to use abstraction: It's make code
clear when you have to break it to manageable parts, which possibly surface
reusable parts, it also makes thing look simple, and even novices may
understand what's going on there. After I die (I mean, when you're not in
NET anymore -- for whatever reasons that may be. Maybe you turned to
buddhist or something or your wife said she divorce if you don't stop that
NETting thing and concentrate your energy on her), someone else understands
it too.
So, naturally I can t agree with any of your arguments you wrote
for keeping it "in the native regexp format" :-)
1) Although you won't maintain it, it is example for others.
2) You can write cryptic regexps or break them into parts where
the whole looks much simpler. Consider novice's welfare :-)
This has nothing to do with the "It never changes in my lifetime".
3) Having some more varaibles and saying it's slower isn't
something we could even measure in practise. CPU won't even hick.
An extra `formail' call in your recipes is 50x expensive than
100 variables. (I don't know how to measure that, but launching
shell and creating process is much more expensive task)
4) Cluttering the env process? C'm on. That won't matter either.
No outside process uses lowecase environment names, or then
it must be real special program.
Sorry, I couldn't resist another view point :-)
jari