www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SCHEDULED for deprecation

reply Tomasz Sowi&#324;ski <tomeksowi.remove.this gmail.and.this.com> writes:
This phrase gave me an idea for a small feat:

deprecated(2009-4-19) void foo();

Compiling references to the deprecated declaration *before* the deprecation
date would result in a *warning*.
Compiling the deprecated declaration OR any reference to it *after* the date
would result in an *error*.

Advantages for maintanance are obvious, plus, the feature seems easy to
implement. What do you think?

Tomek
May 07 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 07 May 2009 20:57:36 +0400, Tomasz <Sowi&#324> wrote:

 This phrase gave me an idea for a small feat:

 deprecated(2009-4-19) void foo();

 Compiling references to the deprecated declaration *before* the  
 deprecation date would result in a *warning*.
 Compiling the deprecated declaration OR any reference to it *after* the  
 date would result in an *error*.

 Advantages for maintanance are obvious, plus, the feature seems easy to  
 implement. What do you think?

 Tomek

It should rather have an optional boolean condition (and a string message): version = ReplacementIntroduced; deprecated(ReplacementIntroduced, "Use foo2() instead") // optional message void foo(); Here is another example: deprecated(__DATE__ > toDate!("2008-04-19")) void foo();
May 07 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
<Tomasz Sowi&#324>; "ski" <tomeksowi.remove.this gmail.and.this.com> wrote 
in message news:gtv3u0$2q00$1 digitalmars.com...
 This phrase gave me an idea for a small feat:

 deprecated(2009-4-19) void foo();

 Compiling references to the deprecated declaration *before* the 
 deprecation date would result in a *warning*.
 Compiling the deprecated declaration OR any reference to it *after* the 
 date would result in an *error*.

 Advantages for maintanance are obvious, plus, the feature seems easy to 
 implement. What do you think?

Deprication should not work like that. Deprication should be based on versions, not actual dates. Basing it on dates like that can cause a number of different problems for, and can even be considered disrespectful to, your API's users. If/when you reach a point where you decide it's time for something to be depricated, you should put out a new release. Even if you have a way to know for certain that release will actually occur on-time, then there would clearly be no problem in just waiting until that point to put out a release that depricates the old stuff. Plus, that way you're not rudely attempting to force the hand of your API user. If they're ok with something being depricated, then they can upgrade to the newest version at their own will, whevever *they* decide it's time for *them* to do so. As far as the idea of "deprication warning and then later a deprication error", we already have something that's...almost...just as good: If you get a deprication error but you're not yet ready to convert, there's a compiler switch to allow depricated stuff. However, I say "*almost* as good" because thanks to DMD's complete inability to treat warnings AS warnings (instead of always insisting on treating them as errors, http://d.puremagic.com/issues/show_bug.cgi?id=2567 ) it's impossible to get a complete list of depricated references in a program (and even that would only happen if deprications were able to be considered warnings at all).
May 07 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Nick Sabalausky wrote:
 <Tomasz Sowi&#324>; "ski" <tomeksowi.remove.this gmail.and.this.com> wrote 
 in message news:gtv3u0$2q00$1 digitalmars.com...
 This phrase gave me an idea for a small feat:

 deprecated(2009-4-19) void foo();

 Compiling references to the deprecated declaration *before* the 
 deprecation date would result in a *warning*.
 Compiling the deprecated declaration OR any reference to it *after* the 
 date would result in an *error*.

 Advantages for maintanance are obvious, plus, the feature seems easy to 
 implement. What do you think?

Deprication should not work like that. Deprication should be based on versions, not actual dates. Basing it on dates like that can cause a number of different problems for, and can even be considered disrespectful to, your API's users. If/when you reach a point where you decide it's time for something to be depricated, you should put out a new release. Even if you have a way to know for certain that release will actually occur on-time, then there would clearly be no problem in just waiting until that point to put out a release that depricates the old stuff. Plus, that way you're not rudely attempting to force the hand of your API user. If they're ok with something being depricated, then they can upgrade to the newest version at their own will, whevever *they* decide it's time for *them* to do so. As far as the idea of "deprication warning and then later a deprication error", we already have something that's...almost...just as good: If you get a deprication error but you're not yet ready to convert, there's a compiler switch to allow depricated stuff. However, I say "*almost* as good" because thanks to DMD's complete inability to treat warnings AS warnings (instead of always insisting on treating them as errors, http://d.puremagic.com/issues/show_bug.cgi?id=2567 ) it's impossible to get a complete list of depricated references in a program (and even that would only happen if deprications were able to be considered warnings at all).

Yes. It's a matter of principle, that a compiler should behave the same, no matter what the wall clock says. (Commercial beta versions excluded, which totally stop working at a fixed date, but that's different.) What could be useful is a switch --show-deprecated that simply puts out a list of the currently deprecated functions and things. But that's asking for too much, I admit. Rather, the change log would be the right place for that. There they should be in one place, diligently listed.
May 07 2009
parent =?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= <tomeksowi.remove.this gmail.and.this.com> writes:
Georg Wrede Wrote:

 Yes. It's a matter of principle, that a compiler should behave the same, 
 no matter what the wall clock says. (Commercial beta versions excluded, 
 which totally stop working at a fixed date, but that's different.)
 
 What could be useful is a switch --show-deprecated that simply puts out 
 a list of the currently deprecated functions and things. But that's 
 asking for too much, I admit. Rather, the change log would be the right 
 place for that. There they should be in one place, diligently listed.
 

I proposed this because, from my experience, no one would switch such a switch. Time-pressure erradicates all thoughts about maintanance, as long as it works/compiles. Tomek
May 09 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 07 May 2009 12:57:36 -0400, Tomasz Sowi&#324;ski wrote:

 This phrase gave me an idea for a small feat:
 
 deprecated(2009-4-19) void foo();
 
 Compiling references to the deprecated declaration *before* the
 deprecation date would result in a *warning*. Compiling the deprecated
 declaration OR any reference to it *after* the date would result in an
 *error*.
 
 Advantages for maintanance are obvious, plus, the feature seems easy to
 implement. What do you think?
 
 Tomek

You should deprecate on the release it is deprecated and not before. However, providing a version for which the function would be removed entirely... And stating the alternative might also be nice. Though these things could be placed in proper documentation, it is nice to have them readily available when you are told it is deprecated.
May 08 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Tomasz Sowi&#324;ski wrote:
 This phrase gave me an idea for a small feat:
 
 deprecated(2009-4-19) void foo();
 
 Compiling references to the deprecated declaration *before* the deprecation
date would result in a *warning*.
 Compiling the deprecated declaration OR any reference to it *after* the date
would result in an *error*.
 
 Advantages for maintanance are obvious, plus, the feature seems easy to
implement. What do you think?
 
 Tomek

Put this in the control of the library creator. Have scheduled_for_deprecation and deprecated.
May 10 2009