ietf-mta-filters
[Top] [All Lists]

Re: variables: open issue a) date variables

2003-05-04 15:19:14

[Marc Mutz]:

  Come on. I thought we agreed that writing to system variables is a
  bad idea...

I don't agree that ${year} is a system variable.

  > I think an explicit action to set them is easier to handle 
  > than a multitude of variables which can change as side-effects.
  
  But they _do_ change as side effects. You can't go and pretend
  they don't.

I wouldn't say it's a side effect, SETDATE is quite explicit.  nothing
else will change the variables.

  > 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.
  
  So what should ${_internal_startup_hour} be other than a system
  variable?

${_internal_startup_hour} doesn't exist...

  > what actions can influence ${_imapflags}?  how will its value
  > change?
  
  ${#imapflags} is (if resolved) a space-separated list of imap
  flags. The order of flags in ${#imapflags} is undefined (it's
  conceptually a set).

so

  if string :matches "${#imapflags}" "*\\Answered*\\Flagged*" {
    ...
  }

may or may not match even if both flags are set.  (easily fixed, just
specify lexical sorting of the "set" at all times.)

  addflag
  - adds the flags given as arg to #imapflags then
  - removes all duplicates.
  
  removeflag
  - removes all flags given as arg from #imapflags

wouldn't it be better to make generic functions for this?
    addflag "flag" "\\Flagged";
changes ${flag}.  you'd now use
    keep :flags "${flag}";
rather than
    keep :globalflags;
and
    keep :flags "${flag} \\Flagged";
instead of
    keep :globalflags_plus "\\Flagged";

some scripts may become more verbose, but the complexity of the
IMAPFLAGS is decreased, IMO.  (ADDFLAG and REMOVEFLAG could move to a
separate extension.)

  setflag
  - clears #imapflags
  - executes addflag <args>

what would SETFLAG "${#imapflags}" do?  just one of those things which
need to be clarified.

  mark
  - equivalent to addflag "\\Flagged"
  
  unmark
  - equivalent to removeflag "\\Flagged"

what is the rationale for MARK and UNMARK?  according to the draft
these actions are _not_ equivalent to ADDFLAG "\\Flagged".

  Summary:
  There are two issues, let's separate them:
  1. Should set be allowed to act on system variables?
     I hope to have made it clear that that's a bad idea.

I strongly agree!

  2. Should system variables be prefixed?
     Well, why _not_? If it makes set's job easier to determine if
     something is read-only or not? If it makes system variable
     references more explicit?

I don't want to introduce system variables at all.  I haven't seen a
compelling case for adding them.

-- 
Kjetil T.