Heh, perhaps... ^_^ Though I'm more likely to do some DB+API evil and attempt to eliminate all the hardcoded SQL inside of the API.
Though, to say the truth I don't know how well I'd fit in the API. I honestly have a strong dislike of supporting real old things. While I do try to keep backwards compatibility in the rest of MediaWiki, there are many cases where where we break things for the extensions that interact with the software. When it comes to my extensions that's a whole strong case. I only support alpha and the latest stable (well, 1.13 came out, so I might support 1.12 for a few more months). Actually I have a few real complex extensions which only support recent versions of 1.14a, but of course those are special cases using real extreme parts of the parser which I've actually had to add to the parser myself. But really, one of my old morales was "Upgrades are for features and fixes... If you want features, then upgrade. There is no reason to support a new feature in an old version of the software. If someone wants the feature, then they can upgrade. It is the same software, it merely has a different version number and more features."
^_^ Actually, on an unrelated note... I wish I'd stop seeing these /extensions/.../install.php files. Does anyone not remember that we have a hook inside of update.php which allows extensions to add new SQL updates into the update system? ;)
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com)
Roan Kattouw wrote:
Daniel Friesen schreef:
;) And then there are a few of us who get intimate with a fair percent of the complex and isolated interfaces, enough to scare themselves. T_T Some time ago, I came to realize that I had actually started to grasp an understanding of how the Parser worked. The preprocessor as well. Nearly all my new ParserFunctions use SFH_OBJ_ARGS and some even do scary things with the frames. When someone asks what function to use in a hook or a tag to do something with the parser, I actually understand what part of the parser will best do that for them (Without needing to trudge around the functions and make a bad guess), and even worse... T_T I'm actually rewriting a portion of the parser myself... And I'm starting to make use of parseresque code in my own work.
As for the other, anyone remember my rewrite of the Database class's titleName method. And my suggestion for a doQuery arg (though that was changed into a backend function that works with strings).
Actually, I'm building my own Database library. Heh, now that's the scary portion. I even implemented Brion's idea for a RawSql class ( Trust me ;) it works quite nicely, it even inspired the RawMarkup class inside of my markup abstraction library (similar to the Xml class))
You're welcome to help out us API devs, if that's your next step ;)
Roan Kattouw (Catrope)