I don't think it is meaningful to add a general function. consider
SETDATE, which had an optional parameter for the timezone.
I agree. The need for extension-specific parameters makes a general
function
infeasible.
<snip>
I agree here as well. The cost of doing what's necessary to bind a fair
number of different variables to a set of values is the only thing that
makes this whole idea somewhat attractive. But the code of binding
one or two variables, which is what you'd have in the case of spamtest
or virustest, is so short that I just don't see the need for a separate
variable binding action.
Great, well as you can guess I'd much rather these variables were just made
available, and we didn't need a setvariables, so where are we now? Are we
saying that spamtest should be revised to specify that it defines certain
variables in a spamtest namespace, and we have a new extension that if
requested makes a list of message attributes available as variables, and we
don't need any special action to ask that they be initialised? Instead
sensible implementations will only evaluate costly variables in a lazy
fashion so as to avoid resource overhead?
So my SMS string has become:
set "Message" "[To: {$header.to} From: ${header.from}] ${header.subject}"
And my "magic string" has become:
addheader "X-Spam-Score" "${spamscore.score}";
?
Nigel