On Mon, 22 Jun 2015 at 09:00 Legoktm <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
