4 ms·

You can still mark it deprecated, even if you don't actually get around to removing it - code that gets recompiled will see the warning and hopefully fix it, an

You can still mark it deprecated, even if you don't actually get around to removing it - code that gets recompiled will see the warning and hopefully fix it, and that which doesn't will still work.

derefr 9y ago
Deprecation can serve three purposes: 1. to get people away from a bad practice; 2. to enable rearchitecture or refactoring that can't take place with a function of the old style "in the way"; and 3. to reduce maintenance burden. Indefinite deprecation without removal helps with #1, but doesn't aid either #2 and #3—and without those additional benefits, usually there's no point: if you're going to be maintaining the function in perpetuity anyway, and won't be able to change the framework out from under the function, then people may as well keep using the function. Keep in mind, also, that "deprecation" can't do much to control Windows developers; they make full and willing use of even private APIs, raw writes to private registry keys, etc. whenever they find them. Microsoft tries to keep compatibility even with these programs. With such developers around, deprecating a feature doesn't change much; as long as it's there, and calling it works, people will continue shipping code that calls it despite the warnings. They'll even write new code that calls it. And a third argument: sometimes Microsoft deprecates a particular API for accessing some functionality, and doesn't go on to provide any alternative API for that functionality. And this isn't a case where they're saying "you just shouldn't be trying to do that any more"; these are cases where there is MSDN documentation that tells you how to idiomatically do something... by using a deprecated function. This taints the "reliability" of deprecation as a useful signal for Windows developers. Those three effects together mean that Microsoft mostly just doesn't bother. Instead of trying to evolve APIs at all by deprecating old features and then refactoring the API surface once the old functions are "out of the way", Microsoft simply write entirely new APIs, leaving the old APIs in place. The old DLL is still there, and still maintained. It might sometimes have been hollowed out into a shim wrapper that calls into the new API... but it's very unlikely, because that destroys "bug for bug" compatibility.

You can still mark it deprecated, even if you don't actually get around to removing it - code that gets recompiled will see the warning and hopefully fix it, and that which doesn't will still work.

derefr 9y ago

Deprecation can serve three purposes: 1. to get people away from a bad practice; 2. to enable rearchitecture or refactoring that can't take place with a function of the old style "in the way"; and 3. to reduce maintenance burden. Indefinite deprecation without removal helps with #1, but doesn't aid either #2 and #3—and without those additional benefits, usually there's no point: if you're going to be maintaining the function in perpetuity anyway, and won't be able to change the framework out from under the function, then people may as well keep using the function. Keep in mind, also, that "deprecation" can't do much to control Windows developers; they make full and willing use of even private APIs, raw writes to private registry keys, etc. whenever they find them. Microsoft tries to keep compatibility even with these programs. With such developers around, deprecating a feature doesn't change much; as long as it's there, and calling it works, people will continue shipping code that calls it despite the warnings. They'll even write new code that calls it. And a third argument: sometimes Microsoft deprecates a particular API for accessing some functionality, and doesn't go on to provide any alternative API for that functionality. And this isn't a case where they're saying "you just shouldn't be trying to do that any more"; these are cases where there is MSDN documentation that tells you how to idiomatically do something... by using a deprecated function. This taints the "reliability" of deprecation as a useful signal for Windows developers. Those three effects together mean that Microsoft mostly just doesn't bother. Instead of trying to evolve APIs at all by deprecating old features and then refactoring the API surface once the old functions are "out of the way", Microsoft simply write entirely new APIs, leaving the old APIs in place. The old DLL is still there, and still maintained. It might sometimes have been hollowed out into a shim wrapper that calls into the new API... but it's very unlikely, because that destroys "bug for bug" compatibility.