On Friday 02 May 2003 01:04, Kjetil Torgrim Homme wrote:
<snip>
the current list is ${year} ${month} ${day} ${hour} ${minute}
${second} ${timezone}, all numeric and zero-padded.
There are two issues I have with this:
1. We define magic variables and don't provide a mechanism for other
extensions to register their own magic variables.
2. We combine two basically unrelated extensions ("variables" and
"dates") into one.
Short comment: Define a namespace for magic variables and move the date
variables out into the to-be-written draft defining the date test.
I have no problem with defining a magic variable namespace. In fact
in some way I'd prefer it. That being said, however, I have a big
problem with defining it and not using it in the same document. All
too often this leads to issues being left open and problems not being
spotted until too late.
Long comments:
Let's assume for the moment that "variables" didn't include "dates", but
defined a syntax for magic variables[1]. "dates" would encompass the
date test Ned wanted to write an I-D for and - in the presence of the
"variables" extension - would define certain magic variables "#year",
"#month" etc.
ad 1: Change the variable-name production to read
variable-name := num-variable / magic-variable / user-variable
magic-variable := "#" identifier
user-variable := identifier
and require every Sieve extension to define their magic-variables and
which commands change their state and how. This is more like how common
script languages (bash, awk, perl,...) work and it provides a namespace
for magic (or "system") variables alike to perl's $<non-alnum>
variables.
I'd somewhat prefer to use $ for the prefix, but it works either way.
ad 2: The "dates" extension would then use this mechanism to declare
#year, #month, #day, #hour, #minute, #second and #timezone to be system
variables that are initialized to their respective values of the time
of script execution start (local timezone). Since the "setdate" action
now didn't really set the date variables anymore, it would better be
named "settimezone". If executed, these system variable values are
recomputed, based on the new timezone given to "settimezone", but still
representing the time of script execution start.
Works for me.
To see the benefit of the system variable notion, consider the imapflags
extension. This would now declare the #imapflags system variable that
holds the current flags (e.g. as a list of imap flag names separated by
spaces). addflags, setflags and removeflags would then act on the
#imapflags variable, but
set "#imapflags" "${#imapflags} \\Seen"
would be OK, too, of you accept the fact that you can cause problems if
you forget the space before "\Seen". Basically, if you assign to system
variables, it's your own fault. Alternatively, assignment to system
variables could be disallowed. I think would be the the best way to
handle it, since it also prevents users from defining variables in the
system namespace (which wouldn't be too problematic, given that system
variables spring into life only if their extension is require'd).
Fileinto would then use the value of #imapflags to determine the flags
to set on (e.g.) IMAP APPEND.
I kind of like the idea of not being able to assign to system variables.
Ned