On 11 January 2012 19:04, Aaron Schulz aschulz4587@gmail.com wrote:
My inclination is to get rid of the feature for pretty much the reason you mentioned.
In any case, is the point to avoid notices getting added to HTML for wikis with certain extensions? I don't know why a production site would be set to spew notices. Either error log settings or $wgDevelopmentWarnings can handle this. If it's to avoid them in the log, again, $wgDevelopmentWarnings works.
IMO, the notices are most useful for core & extension developers testing their code (who deliberately let all warnings get spewed out). If the dev has time to work other extensions, and has the affected one enabled on the same test wikis that have other extensions being worked on, *then* it might be useful to hide certain warnings. However, it seems better to just delay the deprecation in core a cycle. The use case for the new global just seems too marginal and it seems pretty awkward and hacky.
I generally agree that this is not a good addition. If a developer suppresses warnings, he will then proceed to forget about the warning that was suppressed, that's just a simple fact of life. Then the whole benefit of the warning system is negated; the developer is just as likely to update their version and find that things break as if they had turned off deprecation warnings altogether.
Rather, if a developer upgrades from 1.16 to 1.17 and notices a new interface and a @deprecated warning on the old one, concludes that he cannot fix it until 1.19 is released and he can drop support for 1.16, then upgrades to 1.18 and starts getting warnings, he should hack core to remove the wfDeprecated statement from the old interface. Then when he upgrades to 1.19, the probably-now-forgotten hack is overwritten and the warnings reappear, reminding him that he should now start seriously thinking about reworking the extension code. He can then update, test and release a 1.19-compatible version of the extension before the core function itself is removed in 1.20.
--HM