headers
Tyler Romeo | 7 Aug 2012 14:45
Picon
Gravatar

Re: Deprecation levels

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

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

> On Tue, Aug 7, 2012 at 11:26 AM, Jeroen De Dauw <jeroendedauw <at> 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:
> >
> >
(Continue reading)

Permalink | Reply |
headers
Derric Atzrott | 7 Aug 2012 15:01

Re: Deprecation levels

>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.
(Continue reading)

Permalink | Reply |
headers
Tyler Romeo | 7 Aug 2012 15:03
Picon
Gravatar

Re: Deprecation levels

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

On Tue, Aug 7, 2012 at 9:01 AM, Derric Atzrott <datzrott <at> 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
(Continue reading)

Permalink | Reply |
headers
bawolff | 7 Aug 2012 15:21
Picon

Deprecation levels

> 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
 <at> 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
Permalink | Reply |

Gmane