On 11 January 2012 19:04, Aaron Schulz <aschulz4587(a)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