Rowan Collins wrote:
OTOH, the code *outside* the parser will have to, and
more: if you
want to avoid putting redirects through the parser at all, that code
has to do the following:
1] spot that the page is a redirect
2] determine what it is a redirect to
3] find all the article's entries in the links tables (links,
brokenlinks, categorylinks) and delete all those except the target of
the redirect.
1 has to be done one way or another anyway; 2 and 3 would be natural
side-effects of parsing *any* page before save (unless I've completely
misunderstood the current code structure, or you have some magic way
of avoiding this), so why duplicate them in special case code just for
redirects?
This was very enlightening and convincing. You're right. The parser
should parse redirects.
As I mentioned
before, it is *not* necessary for anyone to "deal with"
anything. People can continue to use the old not-a-parser if they want!
For how long? As new features come along, what are the chances that
they will be back-ported to the not-a-parser?
You're talking as if you're regarding myself as some sort of
authoritative figure who determines the future direction of development.
Open source software doesn't work like that, and especially not MediaWiki.
If people need certain features or certain functionality, then they need
to make sure that they are programmed; if nobody volunteers to do it,
they need to do it themselves. I can't, won't, and should not be
required to, take any responsibility for the effects of my parser on
other system administrators. If people need new parser features
backported, then they need to do it themselves; whether or not this is
difficult should not and cannot be a criterion for the direction of the
development of my parser.
In the hypothetical scenario you are describing, i.e. the old
not-a-parser becoming completely obsolete and outdated, administrators
will either have to use the new parser or enhance the old parser for
themselves. This is their problem and their decision, not mine.
BTW, did anyone ever find a compiler-compiler that
could output PHP?
Myself, I haven't even looked. However, I had already retracted my
original hypothesis that porting a C-based yacc/bison file to PHP would
be easy. I have done quite some C-specific programming here (see
parsetree.c), which can certainly be translated to PHP, but not trivially.
Greetings,
Timwi