I was privy to a #mediawiki conversation between brion/tim where tim pointed
out that at least one person plans to implement a Natural Language
Processing parser for English using StringFunctions just as soon as they are
enabled.

It's pretty obvious that you can implement all sorts crazy algorithms using
StringFunctions. They need to be limited so that is not possible.

On Thu, Jun 4, 2009 at 10:19 AM, Robert Rohde <raro...@gmail.com> wrote:

> On Thu, Jun 4, 2009 at 9:05 AM, Andrew Garrett <agarr...@wikimedia.org>
> wrote:
> >
> > On 04/06/2009, at 3:46 PM, H. Langos wrote:
> >
> >> On Thu, Jun 04, 2009 at 03:55:38PM +0200, H. Langos 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.
> >>>
> >>
> >> I forgot to ask THE question. Is it a bug or is there some good reason
> >> to break backward compatibility?
> >>
> >> And no, programming language cosmetics is not a good reason. :-)
> >>
> >> If something has the same interface, it should have the same
> >> behaviour.
> >> If the old semantics was too awful to bare, the new one should have
> >> been
> >> called #strpos or #fpos (for forward-#pos. #rpos always had the
> >> "-1 return on no-found" behaviour).
> >
> > This should be left as a comment on the relevant revision in
> > CodeReview. Note that it's likely irrelevant anyway, as, in all
> > likelihood, the merge of String and Parser Functions will be reverted.
>
> Two devs, who shall remain nameless unless they choose to take credit
> for it, explicitly encouraged the merge.  Personally, I've always
> thought it made more sense to keep these as separate extensions but I
> went along with what they encouraged me to do.
>
> Regardless of whether it is one extension or two, I do strongly feel
> that once a technically acceptable implementation of string functions
> exists then it should be enabled on WMF sites.  (I agree though that
> the previous StringFunctions was rightly excluded due to
> implementation problems.)
>
> -Robert Rohde
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to