> IMO the ACL section of exim has sort of evolved into a type of
> programming language. With that said, what you have stated reminds me
> of some programming techniques that are quite bad. That is passing
> data to routines using global variables. You stated this way of
> programming (Or configuring in the exim sense) is less clutter.
I agree - global variables in many languages are best avoided when possible.
However, with regards to Exim's current language construct, designing local
ACL variables may not actually help clutter. I'll show you what I'm
thinking it might end up looking like in a second...
> warn acl=some_acl($var1, $var2)
> or keeping with the exim sense:
> acl=some_acl{$var1}{$var2}
I figured that would be what a lot of people would think it'd end up looking
like, however where did you get $var1 and $var2 from to pass to the acl? :)
In reality, your line might end up looking like this:
warn set $var1="some data"
set $var2="more data"
acl=some_acl{$var1}{$var2}
Now, replace my nice, uncluttered strings with some real Exim configuration
jibberish (I'm too lazy to dig in my confs to get real world examples - but
many of us know they can be somewhat long lines). As you can see, to make
the call to the acl uncluttered with local variables, you still had to set 2
variables, which could very well be global in the first place and then local
variable passing isn't needed.
Worse yet, say there was a way to execute commands in the call to the acl so
you had something like this:
warn acl=some_acl{if eq {...}{...} etc... {...blah blah...}{else
...}}{{you get the idea...}
Now, tell me that you wouldn't rather see a heap of braces like that then
prefer to keep our global variables?
However, perhaps an overhaul of the entire parsing lexer might be a faaaaar
off wishlist item, and in doing so perhaps may allow for a much nicer,
graceful way of having local variables without all this potential havoc -
THAT's something I'd vote for :P
Or perhaps I've smoked something I shouldn't have and I'm confusing simple
matters (wouldn't be a first)?
Eli.
