(1) The ${0}, ${1} all-digit variables should be set and modified by the
glob-style :matches mechanism in addition to :regex. It really should
not be necessary to implement regex in order to get the ability to
set variables based on message inputs. For example:
This leads to ambiguity, however.
Good point, but it is an ambiguity that is easily resolved simply by saying
glob patterns have to implement greedy matching when variables are used.
What does:
envelope :detail :matches "to" "**"
${1} - full detail field
${2} - empty string
or how about "*a*"?
${1} - String before the last a
${2} - String after the last a.
do? Is it greedy?
AFAIK 3028 didn't say, so the variables document should say that greedy matching
is to be employed.
Also, this draft might be a little surprising to implementors since
something like:
if header :regex "List-ID" ["<alpha(.*)@", "(.*)beta@"] {
fileinto "lists.${1}"; stop;
}
can no longer short circut due to:
"The decimal value of the numeric variable name will index the list of
matching strings from the each of the group operators in the latest
regular expression match."
I don't think that was the intent, and if it was, I think it should be
changed. I read "latest" as meaning "the latest operation that was performed.
So if you have
if header :matches "subject" "*a*" ...
if header :matches "subject" "*b*" ...
where the subject contains both an "a" and a "b" the values of ${0}, ${1}, ...
would be set by the "*b*" pattern.
So _all_ regular expressions have to be tried and the last of the
matches causes the binding.
Big mistake IMO. Short circuit rules should still apply. The base specification
recommends short circuit evaluation of lists. This should be changed to a
requirement when variables are in use. The same is also true of anyof. (Allof
doesn't matter as far as I can tell.)
(5) Other than we decide on something and stick with it, I have no
preference for modifier ordering.
Modifiers should be omitted from this specification. These are
functions; if we're going to define functions, fine. If not, fine.
I have no problem with this approach either.
There are many other problems with this draft, ranging from i18n
concerns: "Variable names are case insensitive." to ones that will
potentially significant problems later on ("All variables have global
scope.").
Given that variable names are explicitly limited to ASCII alphanumeric I fail
to see an issue on this point. As for scope, I think global scope is the right,
and indeed the only realistic, choice.
Ned