On 2011-07-11 17:26:15 -0400, Andrew Wiley <[email protected]> said:
To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category.
To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword.
Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d.
I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view.
-- Michel Fortin [email protected] http://michelf.com/
