I've added a few lightly abstract methods to replace some of the direct
comparisons we make related to namespaces.
When you want to see if a title is part of a namespace, instead of writing
this:
$title->getNamespace() == NS_USER
You can now (or rather, if you don't have compat issues, PLEASE DO use it):
$title->inNamespace( NS_USER );
When you need to make a test if a page is part of a subject or a talk eg
either User or User_talk instead of something verbose like:
$title->getNamespace() == NS_USER || $title->getNamespace() == NS_USER_TALK
Please use:
$title->hasSubjectNamespace( NS_USER );
hasSubjectNamespace will return true if the title's namespace's subject
namespace matches the subject namespace of the namespace you pass in.
If you're writing verbose code testing if a title is in any of a number of
namespaces by using in_array you can use inNamespaces (note the 's'):
$title->inNamespace( NS_USER, NS_TEMPLATE );
To be honest, I don't have any good example use cases on hand of where you
would use that, but I didn't want the lack of that functionality and the
simplicity of in_array to be a valid rationale in not making use of these
abstract interfaces to namespace info.
Likewise there are two MWNamespace methods to match. MWNamespace::equals
and MWNamespace::subjectEquals.
And I DO encourage people making $ns == NS_???? comparisons to use
MWNamespace::equals( $ns, NS_???? ) instead. Even though technically right
now MWNamespace::equals is in fact `return $ns1 == $ns2;`.
This is a little relevant to the "MediaWiki should use a reservation
system for namespaces" bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
The idea is essentially to drop our practice of passing around integers
and instead start passing around keys like "USER", "SMW_PROPERTY",
etc...
MediaWiki would have a namespace registration system where when given a
new key it would reserve a new namespace number for that key.
Instead of extensions being forced to declare what integers they are going
to use and coordinate with other extension developers so that extensions
don't conflict they can instead just make a call to MediaWiki declaring a
string based key like "SMW_PROPERTY" which should not be confusable with
another extension and then MediaWiki will register an integer in the
database for that namespace and reserve it for use with that key. This
also has the benefit that if you install an extension then uninstall it,
you shouldn't lose the contents of the namespace, and when you re-install
it'll start working again without issues like conflicts with titles
created in NS_MAIN that match the prefix used. Theoretically changing the
content language of your wiki from say 'fr' to 'it' could be made in such
a way that MediaWiki won't break existing links and instead the old
i18n'ed NS will end up as an alias.
The idea also fits in with another bug asking for a namespace manager ui.
If we switch to a namespace registration system it will be much easier to
create an administrative ui for this.
Having these abstract interfaces for namespace comparison around will mean
that in the future if we do in fact start passing around things like
"USER" instead of integers, there should be no issue of bugs cropping up
if some code happens to come together and for an unfortunate reason you
happen to have both "USER" and `2` passed from different sources. Making
use of Title::inNamespace and MWNamespace::equals will ensure that even if
you have "USER" and `2` they will be considered equivalent. Unlike what
would happen if you'd used == directly.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]