• =?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= <tomeksowi.remove.this gmail.and.this.com> May 09 2009

=?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= <tomeksowi.remove.this gmail.and.this.com> writes:

Nick Sabalausky Wrote:

 <Tomasz Sowiñ>; "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.


I wasn't really thinking about library releases from a vendor. In these,
deprecation should be version-based, as you say, so this feature wouldn't be
used.

I was thinking of cases where maintanance is often overlooked, say
quick'n'dirty library modules -- there's no version, it's dumped into the same
repository along with code referencing it. Often someone marks the previous API
deprecated and but removing the code, getting collegaues to rewrite their code
gets pushed in time forever, because there's always too little time to think
about maintanance.

Having a fixed date enforced by the compiler is not really rude then, it
improves communication (people know whether they should hurry, it's all in ddoc
and warnings) and serves as a reminder, for both the programmer and the library
writter. Plus, if someone wants to "snooze" the maintanance wake up call, at
least they have to do it consciously.

Tomek