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.
On Thu, Jun 25, 2009 at 10:01 PM, Robert Rohde <[email protected]> wrote:
> On Thu, Jun 25, 2009 at 8:33 PM, Tim Starling<[email protected]>
> 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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
