Hi,
On Sat, Oct 23, 2004 at 05:32:43PM +0200, Kjetil Torgrim Homme wrote:
On fre, 2004-10-22 at 16:11 -0400, Mark E. Mallett wrote:
These are a few comments on draft-homme-sieve-variables-04 . In another
message, I made some comments about variables in general: specifically
that I'd like to see a time where variables are integrated into the
SIEVE language in a more fundamental way. However I imagine that even
assuming anyone else agreed with me, that goal would take some time to
reach, and that something like this draft would be more immediately
useful. In making allowance for that farther goal, I'd want to see:
- This draft and its capability called something other than "variables"
(maybe "stringvars")
if the capability is integrated, why does the name of an obsolete
extension matter?
Because terminology and labels are sticky. If at some point we have two
different things called "variables" there's ambiguity. Native variables
would have a higher claim to the term; my thought was to reserve that
term for their eventual introduction. As you can see, though, I don't
really have a better alternative; it's natural to think of these things
as "variables" and I don't have an idea for an equally natural term for
non-native variables. But the fact that I don't have an answer doesn't
mean I don't think it's an issue :-) Anyway it was something to point
out; apparently there's not much (any?) agreement with me.
When a string is evaluated, substrings matching variable-ref SHALL be
replaced by the value of variable-name. Only one pass through the
string SHALL be done. Variable names are case insensitive, so "foo"
and "FOO" refer to the same variable. Unknown variables are replaced
by the empty string.
I'd strongly prefer case sensitivity here.
almost all Internet standards are case insensitive, and I don't think it
is important enough to go against that flow.
I guess I am on the short side of that opinion too :-)
Actually my preference for case sensitivity applies mainly to any future
implemention of native variables, since the trend in languages is for
case sensitivity in variables, and that is what many programmers will be
most comfortable with. I'm mainly concerned with any precedent set
here. I realize that RFC3028 specifies that statements (that is, all
tokens) are case-insensitive; I still think that script writers would
want case sensitive native variables.
The implication
seems to be that namespace-associated variables are read-only; if that's
true, might want to make that explicit.
I don't think we want to restrict them to be read-only, but there needs
to be a new action if they are to change, since SET disallows setting
variables in namespaces.
Right, I was just trying to figure out what the namespaces were getting
at. As you point out, the description of "SET" disallows specifying
a namespace, so my conclusion was that namespace-associated variables
are read-only.
I've lost track of the history: what's the reason for "*" expanding
greedily? Is it to be compatible with what regex does?
yes, I think it would be strange if :matches was non-greedy,
while :regex was greedy. you may be right that the improved usability
is worth it, though.
Yes- it's a problem either way.
incidentally, if we had a "reverse" operator, users could implement
non-greedy themselves:
set :reverse "pattern" "[*] *";
if header :matches "Subject" "*" {
set :reverse "subject" "${1}";
}
if string :matches "${subject}" "${pattern}" {
set :reverse "prefix" "${2}";
set :reverse "actual_subject" "${1}";
}
I'm all in favor of giving script writers options, such as a :non-greedy
option. I don't really get what your ":reverse" does for "set" though.
mm