[Top] [All Lists]

Re: [sieve] Variable expansion issues

2009-10-22 11:59:04
Hi Ned,

NED+mta-filters(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
> I actually disagreed with the exclusion of variables from the first argument 
> 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.

sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>