Change Details

Right now to handle namespace numbers extensions have to hardcode default namespace numbers into their code and define constants with them for use in code. This results in the need to list them in a central place and keep it in mind when writing new code to avoid conflicts. Naturally with the uncollected nature of extension development conflicts arise and there's of course also no safe place for site custom namespaces. Rather than forcing namespace implementation details into all these extensions we should consider instead using some sort of namespace registry in MediaWiki where namespaces try to reserve a namespace for a key such as "SMW_PROPERTY" for SMW's Property: namespace which is currently defined by the NS_SMW_PROPERTY constant. Such a registry may use calls like `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY', 'content' )` and `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY_TALK', 'talk' )` to reserve it's namespaces. Or perhaps for better state a combined `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY' 'SMW_PROPERTY_TALK' )`. When first used MediaWiki will find unused namespace number(s) for the extensions' namespaces and return them. It will save these reservations in a registry for namespaces noting that the namespace numbers have been reserved for the 'SMW_PROPERTY' and 'SMW_PROPERTY_TALK' keys. After that the method will always return the same namespace numbers for those keys when re-called. The registry will persist the registrations even when an extension is installed and won't re-use previously reserved namespace numbers unless those are explicitly deleted from the registry by someone who has cleared all the content dependant on them from the database. Naturally when an extension is re-enabled because it uses the same keys it will resume using the namespaces it reserved before. Nikerabbit notes that in HipHop we can't set constants dynamically. Also it's fairly awkward that we'll likely have to set them post-config so they'll be hard to use in other configs. If possible we should consider attempting to replace numbers and constants in as many interfaces as possible with keys. Replacing the use of NS_SMW_PROPERTY with "SMW_PROPERTY" everywhere and turning namespace numbers into an implementation-detail which is handled exclusively by core while the rest of the code deals in reservation keys. -------------------------- **Version**: 1.20.x **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=7803

Right now to handle namespace numbers extensions have to hardcode default namespace numbers into their code and define constants with them for use in code. This results in the need to list them in a central place and keep it in mind when writing new code to avoid conflicts. Naturally with the uncollected nature of extension development conflicts arise and there's of course also no safe place for site custom namespaces. Rather than forcing namespace implementation details into all these extensions we should consider instead using some sort of namespace registry in MediaWiki where namespaces try to reserve a namespace for a key such as "SMW_PROPERTY" for SMW's Property: namespace which is currently defined by the NS_SMW_PROPERTY constant. Such a registry may use calls like `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY', 'content' )` and `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY_TALK', 'talk' )` to reserve it's namespaces. Or perhaps for better state a combined `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY' 'SMW_PROPERTY_TALK' )`. When first used MediaWiki will find unused namespace number(s) for the extensions' namespaces and return them. It will save these reservations in a registry for namespaces noting that the namespace numbers have been reserved for the 'SMW_PROPERTY' and 'SMW_PROPERTY_TALK' keys. After that the method will always return the same namespace numbers for those keys when re-called. The registry will persist the registrations even when an extension is installed and won't re-use previously reserved namespace numbers unless those are explicitly deleted from the registry by someone who has cleared all the content dependant on them from the database. Naturally when an extension is re-enabled because it uses the same keys it will resume using the namespaces it reserved before. Nikerabbit notes that in HipHop we can't set constants dynamically. Also it's fairly awkward that we'll likely have to set them post-config so they'll be hard to use in other configs. If possible we should consider attempting to replace numbers and constants in as many interfaces as possible with keys. Replacing the use of NS_SMW_PROPERTY with "SMW_PROPERTY" everywhere and turning namespace numbers into an implementation-detail which is handled exclusively by core while the rest of the code deals in reservation keys. -------------------------- **Version**: 1.20.x **Severity**: enhancement **See Also**: T9803

Right now to handle namespace numbers extensions have to hardcode default namespace numbers into their code and define constants with them for use in code. This results in the need to list them in a central place and keep it in mind when writing new code to avoid conflicts. Naturally with the uncollected nature of extension development conflicts arise and there's of course also no safe place for site custom namespaces. Rather than forcing namespace implementation details into all these extensions we should consider instead using some sort of namespace registry in MediaWiki where namespaces try to reserve a namespace for a key such as "SMW_PROPERTY" for SMW's Property: namespace which is currently defined by the NS_SMW_PROPERTY constant. Such a registry may use calls like `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY', 'content' )` and `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY_TALK', 'talk' )` to reserve it's namespaces. Or perhaps for better state a combined `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY' 'SMW_PROPERTY_TALK' )`. When first used MediaWiki will find unused namespace number(s) for the extensions' namespaces and return them. It will save these reservations in a registry for namespaces noting that the namespace numbers have been reserved for the 'SMW_PROPERTY' and 'SMW_PROPERTY_TALK' keys. After that the method will always return the same namespace numbers for those keys when re-called. The registry will persist the registrations even when an extension is installed and won't re-use previously reserved namespace numbers unless those are explicitly deleted from the registry by someone who has cleared all the content dependant on them from the database. Naturally when an extension is re-enabled because it uses the same keys it will resume using the namespaces it reserved before. Nikerabbit notes that in HipHop we can't set constants dynamically. Also it's fairly awkward that we'll likely have to set them post-config so they'll be hard to use in other configs. If possible we should consider attempting to replace numbers and constants in as many interfaces as possible with keys. Replacing the use of NS_SMW_PROPERTY with "SMW_PROPERTY" everywhere and turning namespace numbers into an implementation-detail which is handled exclusively by core while the rest of the code deals in reservation keys. -------------------------- **Version**: 1.20.x **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=7803 T9803