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.
On Thu, Jun 25, 2009 at 10:01 PM, Robert Rohde rarohde@gmail.com wrote:
On Thu, Jun 25, 2009 at 8:33 PM, Tim Starlingtstarling@wikimedia.org wrote:
Aryeh Gregor wrote:
- #len is implemented by [[Template:Str len]]. Running {{str len}} it
on a string of 250 a's gives preprocessor node count 152, post-expand include size 4597 bytes, template argument size 7430 bytes.
- #pos is implemented by [[Template:Str find]]. Trying to find b in a
string of 250 a's gives preprocessor node count 1354, post-expand include size 5740 bytes, template argument size 50320 bytes.
- #substr is implemented by [[Template:Str sub]]. Using the same
string of a's, with start 30 and length 20, gives preprocessor node count 1534, post-expand include size 13400 bytes, template argument size 44578 bytes.
Is there any good reason not to enable these three string functions, at
least?
Those templates can be defeated by reducing the functionality of padleft/padright, and I think that would be a better course of action than enabling the string functions.
The set of string functions you describe are not the most innocuous ones, they're the ones I most want to keep out of Wikipedia, at least until we have a decent server-side scripting language in parallel.
Could you offer a bit more beyond "I don't like it"? A few devs, and you in particular, have expressed dismay over what string functions would do to wiki template code. However, most devs are rarely if ever involved with writing wiki templates.
By contrast, the community of people who do work on such templates have been asking for these functions for literally years and don't seem the least bit afraid that the marginal impact of adding a few more parser functions will bring the house down.
It is hard for me to figure why this case is so peculiar that the devs should block the wishes of the community. Nor do I see why the existence of basic string functionality should be dependent on someone overhauling or replacing the template coding scheme.
-Robert Rohde
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l