Mailing List Archive: Wikipedia: Wikitech

Deprecation levels

Index | Next | Previous | View Threaded

jeroendedauw at gmail

Aug 7, 2012, 2:26 AM

Post #1 of 9 (246 views)
Permalink

Deprecation levels

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.
--
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

datzrott at alizeepathology

Aug 7, 2012, 5:05 AM

Post #2 of 9 (242 views)
Permalink

Re: Deprecation levels [In reply to]

>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

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

krinklemail at gmail

Aug 7, 2012, 5:29 AM

Post #3 of 9 (243 views)
Permalink

Re: Deprecation levels [In reply to]

On Tue, Aug 7, 2012 at 11:26 AM, Jeroen De Dauw <jeroendedauw [at] gmail>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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

jeroendedauw at gmail

Aug 7, 2012, 5:38 AM

Post #4 of 9 (241 views)
Permalink

Re: Deprecation levels [In reply to]

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.
--
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

helder.wiki at gmail

Aug 7, 2012, 5:43 AM

Post #5 of 9 (243 views)
Permalink

Re: Deprecation levels [In reply to]

Indeed:
http://www.gossamer-threads.com/lists/wiki/wikitech/249632

Helder

On Tue, Aug 7, 2012 at 9:29 AM, Krinkle <krinklemail [at] gmail> wrote:
> On Tue, Aug 7, 2012 at 11:26 AM, Jeroen De Dauw <jeroendedauw [at] gmail>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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

tylerromeo at gmail

Aug 7, 2012, 5:45 AM

Post #6 of 9 (243 views)
Permalink

Re: Deprecation levels [In reply to]

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 [at] gmail

On Tue, Aug 7, 2012 at 8:29 AM, Krinkle <krinklemail [at] gmail> wrote:

> On Tue, Aug 7, 2012 at 11:26 AM, Jeroen De Dauw <jeroendedauw [at] gmail
> >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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

datzrott at alizeepathology

Aug 7, 2012, 6:01 AM

Post #7 of 9 (243 views)
Permalink

Re: Deprecation levels [In reply to]

>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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

tylerromeo at gmail

Aug 7, 2012, 6:03 AM

Post #8 of 9 (241 views)
Permalink

Re: Deprecation levels [In reply to]

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 [at] gmail

On Tue, Aug 7, 2012 at 9:01 AM, Derric Atzrott <datzrott [at] alizeepathology
> 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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

bawolff+wn at gmail

Aug 7, 2012, 6:21 AM

Post #9 of 9 (243 views)
Permalink

Deprecation levels [In reply to]

> 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.

+1. Things should be deprecated, or not deprecated.

If something is deprecated, it should not be used whatsoever in core
or extensions (that are in the Wikimedia repo). It should be the
person adding the wfDeprecated()'s responsibility to ensure that there
are no uses in core or extensions.

I am not a fan of hidden "Deprecated in some future version" thingies.
If there is something wrong enough with the code to deprecate it, it
should be deprecated immediatly. I do think its ok to occasionally
have "It's ok to use this function in old code, but new code should
use other function x", but such code should at most have an
@deprecated on it. It shouldn't generate warnings until such a time as
it is no longer used anywhere in core.

If something deprecated is still used in core, it is perhaps a sign
that whatever is replacing the deprecated function isn't a sufficient
replacement.

--
-Bawolff

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads