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)