Hi Ned,
NED+mta-filters(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
> I actually disagreed with the exclusion of variables from the first argument
to
> set here. But that's water long since under the bridge.
>
[...]
>
> Since I disagree with the exclusion of set, I also am opposed to this
> expansion. And even if I were to agree to this in principle (which I don't),
> I would still object to this change on the grounds that it makes
> currently conforming implementation nonconformant for no good reason.
>
[...]
>
> I understand the logic behind such exclusions. I just don't agree that the
> supposed benefits are worth the loss in flexibility.
>
Although I tend to agree with your appreciation for flexibility, I also
value consistency. My implementation does not support constructing
variable names with variable substitutions anywhere, since I assumed all
variable name arguments to have similar requirements as the set
command's variable name argument (e.g. for hasflag). Now I am wondering
whether I should implement support for this anyway. Did you?
Well, I wouldn't go so far as to say "implement support", because that sounds
like a bunch of work. The routine in my implementation that computes parameter
values takes an argument specifying whether or not to perform variable
expansion in a given case. So for me changing the semantics so that, say, the
first argument of set allows variable expansions is simply a matter of changing
FALSE to TRUE in one call.
I even have the parameter set to TRUE for arguments to body, but if you
actually use a variable substitution in such an argument you're very likely to
get a run time error. As I explained previously, the alternative was not to
implement any form of body test.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve