[Marc Mutz]:
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.
they are not really magic. you can do
SETDATE;
SET "year" "${year} AD";
unless you call SETDATE, no variables in your name space will be
touched.
2. We combine two basically unrelated extensions ("variables" and
"dates") into one.
yes. but do we gain anything by splitting the two? "dates" would
require "variables", and the implementation impact of "dates" is quite
low, especially compared to "variables".
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 don't think we need magic variables. I had them in my very first
draft, but threw them out since I couldn't see a good use for them.
we'd need a registry for known magic variable names, since extensions
could conflict. actions updating variables doesn't need that -- if
they stomp on each others variables, the user will know from the spec
and take whatever action is necessary to save aside any data needed.
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).
nice, but you can get the same capability by adding an action
IMAPFLAGS which updates the value of ${imapflag}. (this might be a
good idea, actually.)
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".
that's just _too_ magic :-)
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).
yes.
--
Kjetil T.