tylerromeo at gmail
Aug 7, 2012, 6:03 AM
Post #8 of 9
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.
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
> >I don't think this is a very good idea at all. The real problem has to do
> >the definition of a deprecated feature. If a feature has been deprecated,
> >it should no longer be used (at least not in the core).
> >Inventing soft deprecation for features that have been superseded but have
> >to be actually replaced is just a lazy way of putting off fully
> >something. Yes, there should probably be some sort of configuration option
> >turn on/off deprecation warnings entirely, and I think the whole
> >$wgDeprecationReleaseLimit is a good approach to this, but there shouldn't
> >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
> go that route then I think that we should treat all deprecation the same.
> "Congratulations, you've just made developer warnings and your IDE's
> deprecation warnings useless due to the amount of noise. These functions
> used WIDELY across the core, so deprecation should be as soft as possible.
> suggest to revert these commits (why merge them so hastily, anyway?!) and
> revisit this issue when MW core and popular extensions will be (mostly)
> 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
> 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
Wikitech-l mailing list
Wikitech-l [at] lists