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 schrieb:
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 ); ^^^^^^^^^^^^
^ Did you miss something? Bergi
On Tue, 22 Nov 2011 06:15:27 -0800, Bergi a.d.bergi@web.de wrote:
Daniel Friesen schrieb:
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 ); ^^^^^^^^^^^^
^Did you miss something? Bergi
Heh, sure.
Maybe I should reconsider my decision to separate inNamespaces from inNamespace?
Hi Daniel, thanks for letting us know.
Could you please add the relevant details to http://www.mediawiki.org/wiki/Manual:Extension_support/1.19/ExtUpgradingand http://www.mediawiki.org/wiki/Manual:Extension_support/1.18/ExtDowngrading so that extension programmers know what to do?
Thanks, Olivier Beaton
On Tue, Nov 22, 2011 at 9:04 AM, Daniel Friesen lists@nadir-seen-fire.comwrote:
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]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hmm... I see what you're going for but I might suggest a tweak.
I think we would continue to pass integers around under a registration system, but you'd look them up (at least for non-builtins) through a function eg MWNamespace::getByKey('CoolExt') rather than a global construction or variable.
There would be no need to change existing comparisons using existing constant keys, and if we did change them we'd maybe want to use symbolic keys instead of the constants.
-- brion On Nov 22, 2011 6:04 AM, "Daniel Friesen" lists@nadir-seen-fire.com wrote:
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]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org