On 05/10/16 17:55, Vladimir Ivanov wrote:
>>> My interpretation of Martin's comment is that using deprecation for
>>> things that aren't actually broken just means that people will live
>>> with lots of deprecation warnings in their code for years to
>>> come. This could be a perfect case for introducing a weaker
>>> alternative to deprecation, saying "here's something better that you
>>> should really be using for new code" -- e.g. ArrayList vs. Vector. I
>>> remember the Guava team talking about that a lot. Don't know if they
>>> ever implemented it.
>>
>> OK. But we really do need a way to do that.
> Doesn't enhanced deprecation [1] in 9 cover that?
I can't tell. As far as I can see there is no annotation which
covers exactly our case:
the API is flawed and is impractical to fix,
usage of the API is likely to lead to errors,
the API has been superseded by another API,
the API is obsolete,
the API is experimental and is subject to incompatible changes,
or any combination of the above.
we'd perhaps need to add
this method over here is better in most cases
...which perhaps implies obsolescent rather than obsolete.
Andrew.
