On Saturday 10 May 2003 04:14, Kjetil Torgrim Homme wrote:
<snip>
This might work - for imapflags. What about ${#currentdate},
${#size} (see below).
these aren't suitable for a list type, are they?
<snip>
That's not the point. The point is that list variables solve this
particular problem (if at all, see the duplicates problem). I've seen
no other example of their usefulness outside the "nice to have"
department.
System variables solve all "internal variable" problems, not only
imapflags. And with a common concept.
you'd need to
set "foo" [ "@{undef}" ];
to reset foo to the empty list.
<snip>
If at all, I'd prefer an unset action for that.
set "flags" "${flags} \\Flagged "; # note trailing space
if string :matches "${flags}" "* \\Flagged *" {
set "flags" "${1} ${2}";
}
Ugh. Too subtle. It's a open invitation for bugs in scripts.
possibly. if this code is given in the documentation, that would
reduce the error rate quite a bit.
<snip>
Unlike the matches-set idiom, this is not generally applicable and I
still maintain the view that it's too fragile.
> # now we want to restore the flags to the values before the
> if. # or do we?
<snip>
you snipped my "sorry, I can't come up with a credible example",
which is what "or do we" is about. why would we ever need to restore
the flags?
<snip>
To get rid of the numerous fileinto tagged arguments that imapflags
defines. There would be only :globalflags semantics left. "local" flags
can be had with
set "saveflags" "${#imapflags}";
setflags "\\Seen";
fileinto "low-priority";
setflags "${saveflags}";
This is more flexible than the multitude of :flags +-= :globalflags +-=
tags, which are unified into the common concept of manipulating
variables.
an ISO 8601 date comparator is not
needed, since a normal string compare is enough.
Please explain why "a normal string compare" is enough to determine
which of the two dates
Sat, 10 May 2003 21:18:44 +0200
Sat, 10 May 2003 20:18:44 +0000
is earlier.
Should every foo test
have a corresponding setfoo action that optimizes away the
otherwise necessary matches-set idioms?
that's the big question, isn't it? the matches-set idiom seems
clunky, a hack. I don't want to base the design of the language on
it.
<snip>
The problem is again the already defined tests. It's one thing to let
the variables extension add system variables for basic Sieve or the
extensions already implemented/out. It's another thing to let it add a
load of _actions_, whose availability is determined by a combination of
extensions.
[2] And one which the variables spec needs to define, so it
addresses Ned's concerns about defining a concept and not
instantly making use of it.
which concept?
That of system variables.
What do you mean with "generic mechanism"? Isn't "system
variable" such a generic mechanism?
every system variable will behave differently. I don't think that's
"generic".
Define "behavior". Different system variables behave as differently as
different actions do, as different tests do. Still, you wouldn't say
that "action" or "test" is not a generic concept, or would you?
Marc
--
Eternal vigilance is the price of liberty -- Thomas Jefferson
pgpi395kfdTM3.pgp
Description: signature