On Thu, Jun 25, 2009 at 9:07 PM, BrianBrian.Mingus@colorado.edu wrote:
They want the functionality and they are willing to satisfy usability and quality of implementation in order to get it, plain and simple. ParserFunctions combined with StringFunctions is flat out unreadable. We should not facilitate the writing of unreadable code.
As an example, yesterday I wrote some code that basically says, "check the doi and http template parameters and check to make sure they begin with http, and if not add it." In any reasonable sort of language that lends itself to a reasonable sort of implementation. But not with Parser and String Functions.
#[[{{{1}}}]]. {{#if:{{{4}}}|[|{{#if:{{{5}}}|[}}}}{{#if:{{#pos:{{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}}}}}|http|}}|{{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}}}}}|{{#if:{{{4}}}| http://dx.doi.org/%7B%7B%7B4%7D%7D%7D%7C%7B%7B#if:%7B%7B%7B5%7D%7D%7D%7Chttp... {{#if:{{{2}}}| {{{2}}}}}{{#if:{{{4}}}|]|{{#if:{{{5}}}|]}}}} {{#ifexist: File:{{{1}}}.pdf |[{{filepath:{{{1}}}.pdf}} (PDF)]|}} {{#if:{{{3}}}| ''{{{3}}}.''}}
There is some extra stuff in there, but you get my point. Just because a few people really, really want extra functionality at any cost doesn't mean much.
Yes, template code can suck, and that's a fine example. But how is adding or not adding string functions going to make a significant difference to that? How is it different that {{#expr:}} or different from creating {{#if:}} to replace {{qif}}, etc.?
I don't see why the fact that template code is a mess should bear on the orthogonal question of providing string functionality to the community. I'm sure that if someone ever does create a better template coding system then many people will quickly migrate to it, but why should that need to come first?
-Robert Rohde