On 2011-07-11 19:56:28 -0400, "Jonathan M Davis" <[email protected]> said:
The problem with not having a message is that people aren't likely to look at the documentation unless they aren't all that familiar with the function, so people will continue to happily use the function up to the point that it's actually deprecated, and then they'll be surpised when their code breaks (since suddenly needing -d for your code to compile _is_ breaking your code). Walter in particular doesn't like the idea of people suddenly having to go and change their build scripts to use -d or immediately fix their code without any warning, which is why we don't deprecate immediately.
Very true. I take this as an indication that the current implementation of the `deprecated` keyword is too strict by default. If it's bad that using a deprecated function breaks the code by default, then make using a deprecated function non-fatal unless the user asks for it to be fatal.
To me, something scheduled for deprecation means that you know it'll be deprecated eventually, but that for now it's still okay using it. For instance, std.xml could be scheduled for deprecation, once we have a replacement we can deprecate it and nag people about using the new one. If you nag people immediately, then it's almost as good as deprecated already.
That said, there's also the problem that the implementation of the "scheduled for deprecation" messages isn't very good. It'll work for modules, it'll work for template functions, but you don't know who imported the module or called the function. Moreover, calling a deprecated function from within a deprecated function yields no error; calling a scheduled-for-deprecation function from a scheduled-for-deprecation one or even a deprecated one will show an annoying message. Does that makes sense?
Instead of working on fragile workarounds, better fix the problem, which is that `deprecated` is too strict by default.
-- Michel Fortin [email protected] http://michelf.com/
