Hey all,
This thread is much in line with the "wfRunHooks deprecation" one from January. Rather than turning global functions into static functions, this time it's about namespacing global functions.
All extensions calling wfSuppressWarnings now are supposed to change this to MediaWiki\suppressWarnings, for no obvious gain. Important to keep in mind here is that this is not a simple search and replace, since that'd make extensions incompatible with anything before MediaWiki 1.26 alpha. Either we need to ignore the deprecations (which is not something you want people to learn as good practice), or we need to add some kind of wrapper in each extension.
There also is the question of consistency. Nearly all global functions are still namespaced using the wf prefix. Will they all be changed? Or will just a few functions be migrated?
I'd really prefer this kind of busywork for extension maintainers not to be created without very good reason. There are enough breaking changes to keep up with as it is.
Cheers
-- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Developer at Wikimedia Germany ~=[,,_,,]:3
Hi,
On 06/21/2015 01:52 PM, Jeroen De Dauw wrote:
Hey all,
This thread is much in line with the "wfRunHooks deprecation" one from January. Rather than turning global functions into static functions, this time it's about namespacing global functions.
All extensions calling wfSuppressWarnings now are supposed to change this to MediaWiki\suppressWarnings, for no obvious gain.
The gain is that wfSuppressWarnings()/wfRestoreWarnings() is now a separate library[1] that can be used by any PHP project outside of MediaWiki. For example, I have a patch[2] that replaces usage of @ with at-ease in OOUI. We are also planning[3] on creating a separate library for the XMP parsing code in MediaWiki which would use at-ease.
Important to keep in mind here is that this is not a simple search and replace, since that'd make extensions incompatible with anything before MediaWiki 1.26 alpha. Either we need to ignore the deprecations (which is not something you want people to learn as good practice), or we need to add some kind of wrapper in each extension.
Or just don't change anything? It is not going to trigger deprecation warnings anytime soon, and for now it will just incur the overhead of one extra function call. It is recommended that callers move to the namespaced functions, but if you plan on supporting older versions of MediaWiki core, don't.
There also is the question of consistency. Nearly all global functions are still namespaced using the wf prefix. Will they all be changed? Or will just a few functions be migrated?
The "wf" prefix doesn't really make sense in a separate library, so we used a namespace instead. I'm not sure if anyone has plans to library-ize other global functions.
[1] http://packagist.org/packages/mediawiki/at-ease [2] https://gerrit.wikimedia.org/r/#/c/217311/ [3] https://phabricator.wikimedia.org/T100922
-- Legoktm
On Mon, 22 Jun 2015 at 09:00 Legoktm legoktm.wikipedia@gmail.com wrote:
Hi,
On 06/21/2015 01:52 PM, Jeroen De Dauw wrote:
Hey all,
This thread is much in line with the "wfRunHooks deprecation" one from January. Rather than turning global functions into static functions, this time it's about namespacing global functions.
All extensions calling wfSuppressWarnings now are supposed to change this to MediaWiki\suppressWarnings, for no obvious gain.
The gain is that wfSuppressWarnings()/wfRestoreWarnings() is now a separate library[1] that can be used by any PHP project outside of MediaWiki. For example, I have a patch[2] that replaces usage of @ with at-ease in OOUI. We are also planning[3] on creating a separate library for the XMP parsing code in MediaWiki which would use at-ease.
Important to keep in mind here is that this is not a simple search and replace, since that'd make extensions incompatible with anything before MediaWiki 1.26 alpha. Either we need to ignore the deprecations (which is not something you
want
people to learn as good practice), or we need to add some kind of wrapper in each extension.
Or just don't change anything? It is not going to trigger deprecation warnings anytime soon, and for now it will just incur the overhead of one extra function call. It is recommended that callers move to the namespaced functions, but if you plan on supporting older versions of MediaWiki core, don't.
Does MediaWiki dev processes have the equivalent of a "future deprecation" to advertise that a new approach is now available, but the old approach hasnt been deprecated yet and there is no plan in place to issue deprecation warnings when using the old approach?
-- John Vandenberg
Hey,
Thanks for expalining.
I did notice the code now resides in a seperate library. Congratulations on that work. I can see how this provides benefit.
It is also clear that naming it wfSuppressWarnings there does not make a lot of sense. What is not clear to me is why existing MediaWiki extensions that are completely dependent on MediaWiki should now preferrably call the library functions directly. Why do they have to care that this refactoring has been made? If you are writing some new code and are trying to decouple it from MediaWiki, and it needs this functionality, then by all means, use the namespaced one. For existing extensions where such decoupling is not going to happen, I see only cost, not benefit.
I'm not suggesting that the library should not be there, or that the namespacing in it does not make sense. My suggestion is to not deprecate wfSuppressWarnings.
Cheers
-- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Developer at Wikimedia Germany ~=[,,_,,]:3
wikitech-l@lists.wikimedia.org