On Mon, 22 Jun 2015 at 09:00 Legoktm <legoktm.wikipedia(a)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