[Ned Freed]:
> what's your preferred alternative in the imapflags case?
A string containing a list of flags separated by spaces. This is
hardly rocket science.
a string with a predefined name, then? (to cater for MARK/UNMARK.)
> > There are also very substantive syntactic difficulties with making
> > such usage compatible with the base sieve specification.
>
> please state them so that they can be addressed.
They have all been stated before. For exmaple, what syntax do you
use to plug a list variable into an argument to a test? "&list" is
poor. What about "&list &list"? What about ["&list", "&list"].
my current suggestion:
"@{var}" is an error except in a list context. a list variable in
string context interpolates as the concatenation of each value in the
list delimited by a single space. a string variable in list context
is handled as a list with one element. these are equivalent:
set "var" "meep";
set "var" ["meep"];
a string containing multiple list references will be split on the
references, and the list will contain the pre-, in- and post-fixes as
elements in the list.
["@{var} @{var}!"] => ["meep", " ", "meep", "!"]
Sure, you can work around all of this. But it keeps getting uglier
and uglier.
ugliness is in the eyes of the beholder. :-)
And for what? A feature that is nice to have at best?
possibly, but lists are a widespread occurence in Sieve, and I think
it does make sense to be able to represent them in variables.
> > You may not want to deal with them, but it may make sense to
> > implement things using a multi-tiered storage approach.
>
> what do you mean?
I mean I may not want to create variables like year, month, day,
and so on on demand rather than having setdate poke them into the
same structure used for user-defined variables.
alright, so if I understand you correctly, the "multi-tier" is that
you store the time-of-day internally, and populate the user-defined
variables from that when asked to.
> well, it's the alternative to system variables, which I find
> vastly too complex ;-)
The question is whether we actually need them. I've yet to be
convinced we do. But if we do, this can be done as part of a
naming convention, rather than by defining more operators and
such.
I agree.
Exactly. The primary problem with list variables is that they
clash very very badly with earlier design choices, so much so that
we lose considerable language coherency by adding them. Now, you
can argue that earlier design choices were poor ones, but that
doesn't make them go away.
I honestly can't see why list variables clash more badly than plain
variables.
--
Kjetil T.