[Marc Mutz]:
[Ned Freed]:
> I do note, however, that nobody else is jumping in to support
> this prefix idea. I'm ambivalent about it myself.
It's weekend ;-)
weekends seem to be more active than workdays on this list.
if you want a prefix character, use "_". it's part of the identifier
grammar, and has seen similar use in other contexts.
The reasons against magic/system variables Kjetil mentioned were:
1. Year, month, etc. are not really magic, you can write them via set
and they only spring into life on setdate.
I think we agree that writing to those variables is not a good
idea, since it's not needed, makes program flow analysis more
complex
really? I think an explicit action to set them is easier to handle
than a multitude of variables which can change as side-effects. we've
already seen that this is a tricky issue with the match back
references. there the gain for easy access seems great enough to be
worth it. SETDATE can be seen as a macro for
SET "hour" "${_internal_startup_hour}";
SET "minute" "${_internal_startup_minute}";
SET "second" "${_internal_startup_second}";
...
pretty straightforward to analyse, IMO.
what actions can influence ${_imapflags}? how will its value change?
and produces potentially invalid system variable content that
leads to a new class of runtime errors not present with read-only
system variables.
it's not a system variable. it will not lead to more errors than we
get from making changable variables available to the user.
Furthermore, that they spring into life as a side-effect of a
command is proof, not disproof, of their magicness.
see macro comment.
2. There's no good use for them.
Well, the fact that they are being defined (whether called system
variables or not) in itself is proof of their
usefulness. imapflags could also make good use of system
variables. In fact, IIRC, the imapflags extension was was what
prompted the variables extension in the first place.
I wasn't around then. my motivation for writing the draft was to
enable match back references in the argument to fileinto.
3. We'd need a registry for them, since extensions could conflict.
They can still conflict if we don't make system variables explicit
in the variables extension. Prefixing them at least avoids
conflicts with user variables.
no, there can be no conflict, two extensions can use the same variable
name and co-exist peacefully. e.g., you could have two actions
putting its return value in ${result}. the user would just have to do
a SET to save it in another variable before doing the next action, and
he only has to do that if he needs to use the two actions in the same
Sieve run. with your truly magic variables, this can't be done.
As to requiring a registry. Sure, that would be nice, but isn't a
necessity. We don't have a registry for command or test
identifiers either, even though they could also conflict between
extensions. Instead, we believe the extension authors and the
review process to avoid these conflicts.
fair enough.
--
Kjetil T.