Hey,
This is something I've come across several times before when deprecating functions: people want different behaviour with regard to the warnings they get. Typically what people want can be split into two groups:
Weak deprecation: The function is documented as being deprecated but no wfDeprecated is put in
* Pro: People do not get flooded with deprecation warnings when the function is still in use at many places. * Con: It's impossible to actually get warnings for this usage of this function when desired for some purpose. When writing new code, it'd be good to be able to notice you're using deprecated functions. * Con: Many people won't notice they are using deprecated code at all, since not everyone is using an IDE highlighting deprecation and those that don't are definitely not looking at the definition of every function they use.
Strong deprecation: The function is documented as being deprecated and wfDeprecated is put in.
* Pros and Cons: opposite of the above
It's clear each that for different people the same approach might not be preferred. Discussion arises when some people do not want something to be strongly deprecated. What about introducing a soft deprecation function (ie wfSoftDeprecated) that calls wfDeprecated with an additional argument specifying it's a soft deprecation call, which by default does not result in any warnings or notices, but can by means of some setting be turned on by those that want to get them? Such a setting could either be a boolean, int (ie show warnings above this level) or some whitelist of softly deprecated functions one wants to get warnings for. Seems to be pretty trivial to accommodate both groups here, and get rid of the silly discussions.
Any thoughts?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Hey,
This is something I've come across several times before when deprecating functions: people want different behaviour with regard to the warnings they
get.
Typically what people want can be split into two groups:
Weak deprecation: The function is documented as being deprecated but no wfDeprecated is put in
...
Strong deprecation: The function is documented as being deprecated and wfDeprecated is put in.
...
It's clear each that for different people the same approach might not be preferred. Discussion arises when some people do not want something to be strongly deprecated. What about introducing a soft deprecation function (ie wfSoftDeprecated) that calls wfDeprecated with an additional argument specifying it's a soft deprecation call, which by default does not result
in any
warnings or notices, but can by means of some setting be turned on by those
that
want to get them? Such a setting could either be a boolean, int (ie show warnings above this level) or some whitelist of softly deprecated functions
one
wants to get warnings for. Seems to be pretty trivial to accommodate both
groups
here, and get rid of the silly discussions.
Any thoughts?
Cheers
Definitely think this is a good idea. We could name the option $wfShowSoftDeprecated or something similar, but not nearly as long. I noticed that we have a $wgDebugLogFile configuration option. Right now, from what I can tell, it appears to only log SQL errors. I wonder if it might be a good idea to log both soft and hard deprecated warnings there as well.
Thank you, Derric Atzrott
On Tue, Aug 7, 2012 at 11:26 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
This is something I've come across several times before when deprecating functions: people want different behaviour with regard to the warnings they get. Typically what people want can be split into two groups:
Didn't we solve this already by being able to pass a version to wfDeprecation() and allowing users to set $wgDeprecationReleaseLimit to hide/show from whatever cut-off point they desire?
-- Krinkle
Hey,
Didn't we solve this already by being able to pass a version to
wfDeprecation() and allowing users to set $wgDeprecationReleaseLimit to hide/show from whatever cut-off point they desire?
This seems to coarse - people still get mad when adding a wfDeprecated( __METHOD__, '1.20' ), even though that won't get you notices by default. Which is, I guess, because they have wgDeprecationReleaseLimit set to false, so they also get notices for things that have only recently been deprecated. So no, we did not solve this yet.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Indeed: http://www.gossamer-threads.com/lists/wiki/wikitech/249632
Helder
On Tue, Aug 7, 2012 at 9:29 AM, Krinkle krinklemail@gmail.com wrote:
On Tue, Aug 7, 2012 at 11:26 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
This is something I've come across several times before when deprecating functions: people want different behaviour with regard to the warnings they get. Typically what people want can be split into two groups:
Didn't we solve this already by being able to pass a version to wfDeprecation() and allowing users to set $wgDeprecationReleaseLimit to hide/show from whatever cut-off point they desire?
-- Krinkle _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I don't think this is a very good idea at all. The real problem has to do with the definition of a deprecated feature. If a feature has been deprecated, then it should no longer be used (at least not in the core). Inventing soft deprecation for features that have been superseded but have yet to be actually replaced is just a lazy way of putting off fully deprecating something. Yes, there should probably be some sort of configuration option to turn on/off deprecation warnings entirely, and I think the whole $wgDeprecationReleaseLimit is a good approach to this, but there shouldn't be levels of deprecation. A feature should just be deprecated or not.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Aug 7, 2012 at 8:29 AM, Krinkle krinklemail@gmail.com wrote:
On Tue, Aug 7, 2012 at 11:26 AM, Jeroen De Dauw <jeroendedauw@gmail.com
wrote:
Hey,
This is something I've come across several times before when deprecating functions: people want different behaviour with regard to the warnings
they
get. Typically what people want can be split into two groups:
Didn't we solve this already by being able to pass a version to wfDeprecation() and allowing users to set $wgDeprecationReleaseLimit to hide/show from whatever cut-off point they desire?
-- Krinkle _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I don't think this is a very good idea at all. The real problem has to do
with
the definition of a deprecated feature. If a feature has been deprecated,
then
it should no longer be used (at least not in the core).
Inventing soft deprecation for features that have been superseded but have
yet
to be actually replaced is just a lazy way of putting off fully deprecating something. Yes, there should probably be some sort of configuration option
to
turn on/off deprecation warnings entirely, and I think the whole $wgDeprecationReleaseLimit is a good approach to this, but there shouldn't
be
levels of deprecation. A feature should just be deprecated or not.
As I stated earlier, I'm pro-multiple levels of deprecation, but if we don't go that route then I think that we should treat all deprecation the same. This:
"Congratulations, you've just made developer warnings and your IDE's deprecation warnings useless due to the amount of noise. These functions are used WIDELY across the core, so deprecation should be as soft as possible. I suggest to revert these commits (why merge them so hastily, anyway?!) and revisit this issue when MW core and popular extensions will be (mostly) clean."
Should not happen then if a function is deprecated. If we don't want to display the warnings, then we shouldn't deprecate the function.
That or we need to find an alternative solution to the problem. If it makes it any better we could call Soft Deprecation "Function Supersession" or something similar to show that a function has been superseded even if not formally deprecated yet.
Thank you, Derric Atzrott
Mhm. I like the idea of function supersession. Basically, I just don't think we should call a function deprecated unless it actually is indeed deprecated, i.e., no longer used anywhere in the core. Theoretically, a function that is deprecated in the core should not show any warnings whatsoever when testing without extensions.
If we can somehow denote functions that are *planned to be deprecated*, that would be a better solution, and then deprecation would actually occur when all instances of the feature are removed from the core.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Aug 7, 2012 at 9:01 AM, Derric Atzrott <datzrott@alizeepathology.com
wrote:
I don't think this is a very good idea at all. The real problem has to do
with
the definition of a deprecated feature. If a feature has been deprecated,
then
it should no longer be used (at least not in the core).
Inventing soft deprecation for features that have been superseded but have
yet
to be actually replaced is just a lazy way of putting off fully
deprecating
something. Yes, there should probably be some sort of configuration option
to
turn on/off deprecation warnings entirely, and I think the whole $wgDeprecationReleaseLimit is a good approach to this, but there shouldn't
be
levels of deprecation. A feature should just be deprecated or not.
As I stated earlier, I'm pro-multiple levels of deprecation, but if we don't go that route then I think that we should treat all deprecation the same. This:
"Congratulations, you've just made developer warnings and your IDE's deprecation warnings useless due to the amount of noise. These functions are used WIDELY across the core, so deprecation should be as soft as possible. I suggest to revert these commits (why merge them so hastily, anyway?!) and revisit this issue when MW core and popular extensions will be (mostly) clean."
Should not happen then if a function is deprecated. If we don't want to display the warnings, then we shouldn't deprecate the function.
That or we need to find an alternative solution to the problem. If it makes it any better we could call Soft Deprecation "Function Supersession" or something similar to show that a function has been superseded even if not formally deprecated yet.
Thank you, Derric Atzrott
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org