digitalmars.D - Re: SCHEDULED for deprecation
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
May 09 2009