On Thu, Jun 25, 2009 at 9:07 PM, Brian<Brian.Mingus(a)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/{{{4}}}|{{#if:{{{5}}}|http://dx.doi.org/{{{5}}}}}}}}}
{{#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