On Thursday 08 February 2007 19:08, Magnus Holmgren wrote:
> Hello everybody! This is my vision of and suggestion for a reform of the
> string expansion language:
My idea is that expansion strings should be parsed first, then evaluated. That
would make distinguishing parse errors from other expansion failures easier.
If the string expansion language can be made simple, the amount of code can
be reduced significantly. That means that special cases should be eliminated.
> - The special operators that take arguments separated by underscores have
> to become normal:
> ${substr:3:2:$local_part}
While the above is no problem, I think there are three truly special cases:
* $header_Foo: et al. Would it be asking too much if you had to say
${header:Foo} instead? (Should there be a right brace in the header field
name it can simply be escaped with a backslash, as usual). On the plus side
it would eliminate the common mistake of forgetting the terminating colon.
* The user-definable $acl_m_* and $acl_c_* (I can envision an arbitrary number
of $address_data_* variables too). I think this pattern is generic enough
that it can be handled tidily.
* ${lookup}, the only item that requires a parameter (the lookup type)
without braces around it. Unfortunately, the number of arguments can't be
used to distinguish single-key lookups from query-style ones (the last two
arguments are optional). I'd prefer a ${lookup_<type> ...} scheme.
I'm also pondering how to do forced expansion failure if "fail" without braces
is the same as "{fail}". Perhaps a special $fail pseudovariable? Or even
${exception:Catch me if you can!}?
--
Magnus Holmgren holmgren@???
(No Cc of list mail needed, thanks)
"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans
