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 | [email protected]



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

Reply via email to