Hi, Looking at real problems is good, and in this case there’s quite a few layers of issues underlying issues indeed. First the problem of the “get” method underlain by the deprecation issue. As mentioned, the name “get” is a good, proper name for a method. There are no problems with the name itself. The problem is with the implementation backing this name not matching what it should obviously-from-just-reading-the-name be really doing.
A misbehaving implementation is nothing new and is a relatively easy problem to fix. First, not throwing a previously thrown exception should not break too many consumers. Likewise returning a previously not returned value won’t deprive consumers of any values they are relying on getting. Still, some consumers might be broken. On balance, if the evidence presented earlier the thread holds true then many (perhaps quite a few more!) consumers -- currently silently broken -- would get silently mended. As a bonus, returning null and not throwing a NSEE doesn’t disqualify Optional from becoming a value type in future nor prevent it from containing a future value type. The solution to how this is to be done is left as an exercise for the reader. 😊 But yeah, there is a solution. Against this backdrop the suggestion to deprecate the get-method without changing its implementation in essence changes the thrown NoSuchElementException into a quasi-checked exception via creative (ab)use of the deprecation mechanism. That leaves the class with just as many methods with problems as there were in the beginning. If the get-method is then recreated under a different name with all the problems in the implementation left unfixed, Optional ends up with 1 more method with problems than what it started with. This way of “fixing” the problem seems to me like a workaround to deeper issues with the language. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Brian Goetz Sent: Wednesday, April 27, 2016 16:49 To: Stuart Marks; Stephen Colebourne Cc: core-libs-dev Subject: Re: RFR(m): 8140281 deprecate Optional.get() 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
