Re: variables: open issue a) date variables

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