On 4/26/16 9:20 PM, Kevin Bourrillion wrote:
Guava owner here, and yes, I've never heard such a complaint about our
Optional.get() method. This class has about a quarter of a million usages
inside Google alone (I'm not kidding), and people seem quite happy with it.
Hi Kevin, thanks for your comments.
Interesting to hear yours (and Google's) experience with Guava's Optional.get().
How does Google avoid misusing it? Better programmers, better reviews, ability
to refactor globally, or something else? Based on some of the code I've seen in
the JDK and on grepcode.com (posted upthread), perhaps 50% or more of the uses
of the JDK's Optional.get() are bad or suspect.
Usually issues like this can be mitigated with Stack Overflow answers, blog
articles, conference talks, better documentation, etc. But when the rate of
misuse is this high, maybe it means that there's something wrong with the API
itself.
Now it may be the case that a particular proposal to fix the problem creates
more pain than is worthwhile. I'm sympathetic to this, and I'm willing to
discuss variations on or alternatives to proposals that reduce the pain. And I'm
also prepared to accept, after exploring alternatives, that there might not be
any that are sufficiently pain-free to proceed.
But I'm also hearing that "Optional.get() isn't a problem." I'm really surprised
by this. After looking at a bunch of code that uses Optional.get() it really
looks like a problem to me. But maybe somebody can explain to me why it isn't.
We have been planning to migrate these usages from our Optional class to
yours (sounds crazy, but this is how we roll). Threads like this one -- and
the threat of changing Optional in-place incompatibly to become a value
type as part of Valhalla -- are making us, for the first time, seriously
question whether that is such a good idea.
Please don't rename this method.
I'll set aside the issue of value types for this discussion.
We're not proposing to rename the method, strictly speaking. (I did use the word
"rename" in my initial message on this thread. This was imprecise. If this
misled anyone, I apologize.)
A rename is strictly the addition of method and the removal of the old one. This
is source and binary incompatible. We're not proposing that.
We're also not proposing some temporary overlap of the old and the new for a few
releases, after which the old would be removed. If we were to do that, we'd
annotate the old method with @Deprecated(forRemoval=true). But the proposal is
to deprecate with forRemoval=false (which is the default value, so it's elided).
Instead, the proposal is to deprecate the old method, adjust the documentation
to refer to the new method (and other Optional methods) and to leave the old
method there indefinitely. This changes the behavior of IDEs and the way
compilers issue warning messages, but otherwise it's source and binary compatible.
Does this still make you reluctant to migrate to the JDK's Optional? If so, I'd
like to understand this better, in order to improve the proposal.
s'marks
