On Thu, Jun 4, 2009 at 6:55 AM, H. Langos henrik-mw@prak.org wrote:
Seems like (at least) the API of #pos in ParserFunctions is different from the one in StringFunctions.
{{#pos: haysack|needle|offset}}
While the StringFunctions #pos in MediaWiki 1.14 returned an empty string when the needle was not found, the ParserFunctions implementation of #pos in svn now returns -1.
<snip>
Prior to the merge 100% of the StringFunction function calls were reimplemented, principally for performance and security reasons.
The short but uninspired answer to your question is that in doing that I didn't notice that #pos and #rpos had different default behavior. Given the way that #if works, returning empty string is a reasonable response to a string-not-found condition, and I am happy to change that back. I'll also recheck to make sure there aren't any other unexpected behavioral changes.
Though they don't have to have the same behavior, I'd be inclined to argue that #pos and #rpos really ought to have the same default behavior on usability grounds, i.e. either both giving -1 or both giving empty string when a match is not found. Though since that does create compatibility issues with existing StringFunctions users, I'll defer to others about whether consistency would be a good enough motivation in this case.
I should warn you though that there is an intentional behavioral change regarding the handling of strip markers. The pre-existing StringFunctions codebase reacted to strip markers in a way that was inefficient, hard for the end user to predict, and in specially crafted cases created security issues.
The following example is illustrative of the change.
Consider the string "ABC<nowiki>jkl</nowiki>DEF<nowiki>mno</nowiki>GHI"
In the new implementation this is treated internally as "ABCDEFGHI" by the string routines. Hence it's length is 9 and it's first five characters are ABCDE.
For complicated reasons the StringFunctions version says its length is 7 and the first "five" characters are ABCjklDEFmnoG.
-Robert Rohde