So far, this thread has been mostly "I DON'T LIKE THIS CHANGE." But
let's talk about a real underlying issue instead, mkay?
While no one has actually said this (I guess everyone was too busy
slinging rhetoric and raising strawman objections) there is at least one
real issue here, which is:
- I have a library
- I want it to be free of deprecation warnings
- I want it to compile cleanly on platform versions N...N+k, where
something is deprecated with an alternative in M>N, and the alternative
does not exist in N.
That leaves the hypothetical library provider above (which I assume is
Stephen's situation, though it was left unsaid) with some bad choices:
- @SuppressWarnings the use everywhere
- Compile without deprecation warnings
- Have multiple sourcebases
I think the real issue is that @SuppressWarnings is too blunt a tool to
be useful in this situation, so deprecation causes collateral pain for
library developers. If we can make the deprecation more painless for
this class of developers (the ones disproportionately affeted), then I
think much of the noise goes away.
On 4/27/2016 1:42 AM, Stuart Marks wrote:
On 4/26/16 3:43 AM, Stephen Colebourne wrote:
In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this
would be painful and add no value.
Hi Stephen,
I just sent a reply [1] to Kevin B, wherein I clarified "rename."
Briefly, it strictly isn't a rename. The old method would be
deprecated not-for-removal, and would be left in place indefinitely.
Does this still create pain? If so, is there some way the proposal can
be modified to reduce it?
s'marks
