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