FYI: In https://github.com/apache/druid/pull/9111 I've used Optional a bit more; for example see HashJoinSegmentStorageAdapter#getClauseForColumn and Exprs.decomposeEquals. There are still a lot of @Nullable where needed to interact with existing interfaces. I didn't think going on a rampage changing them was a good idea.
Curious what you all think. I'm wondering if we can articulate as a community a coherent null vs. optional policy. Otherwise in practice it will end up being personal preference of the author. On Fri, Oct 11, 2019 at 6:37 AM Jad Naous <jad.na...@imply.io> wrote: > I don't think we need to enforce the use of Optional (at least not to begin > with), but it would be a good idea to use it in new code. > > On Fri, Oct 11, 2019 at 6:35 AM Jad Naous <jad.na...@imply.io> wrote: > > > On using Optional: to me, it was mostly a documentation issue, making it > > easier to no longer have to worry about whether some method will return > > null or whether someone will pass null to a method. It also made it > easier > > to remember to actually check for the existence of something before using > > it. We also used Guava's Optional which is much more pleasant to work > with > > than the JDK's Optional. > > > > On Thu, Oct 10, 2019 at 5:46 PM Gian Merlino <g...@apache.org> wrote: > > > >> For reference, a (brief) earlier conversation about this: > >> https://github.com/apache/incubator-druid/issues/4275, which links to > >> > https://github.com/apache/incubator-druid/pull/4254#discussion_r116628607 > >> , > >> which links to > >> > >> > https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 > >> . > >> > >> I really enjoyed programming with Scala's Option type, back when I had > >> spend a couple of years writing Scala code. They are awesome. Java > >> Optionals are sadly not quite as good, especially in ecosystem support > >> (they're not adopted very well in libraries or in the jdk itself) but > also > >> in functionality (in Scala they're tightly integrated into the > collections > >> library, which allows for some nice idioms). > >> > >> After that Scala break, when I came back to Java I wrote a lot of the > >> indexing service module. You can tell because it has Guava Optionals > >> everywhere. I mostly used it the way that Goetz recommended, as a method > >> return type in commonly used interfaces or utility methods. It was a bit > >> clunky but it was overall nice. I don't regret it. But now I mostly > don't > >> use them anymore, and started using null-returns (with @Nullable > >> annotations) instead since it jives better with the rest of the > codebase. > >> > >> Jad, or anyone else, have you worked on Java codebases where Optional > was > >> heavily used? What was the experience like? > >> > >> Also, has anyone had experience introducing a preference for Optionals > >> into > >> a large pre-existing codebase? > >> > >> On Wed, Oct 9, 2019 at 12:46 PM Jad Naous <jad.na...@imply.io> wrote: > >> > >> > Sir Tony Hoare on inventing null while working on ALGOL (from > wikipedia > >> > below): > >> > > >> > Speaking at a software conference called QCon London > >> > <https://qconlondon.com/> in 2009, he apologised for inventing the > null > >> > reference <https://en.wikipedia.org/wiki/Null_pointer>:[23] > >> > <https://en.wikipedia.org/wiki/Tony_Hoare#cite_note-23> > >> > > >> > I call it my billion-dollar mistake. It was the invention of the null > >> > reference in 1965. At that time, I was designing the first > comprehensive > >> > type system for references in an object oriented language (ALGOL W > >> > <https://en.wikipedia.org/wiki/ALGOL_W>). My goal was to ensure that > >> all > >> > use of references should be absolutely safe, with checking performed > >> > automatically by the compiler. But I couldn't resist the temptation to > >> put > >> > in a null reference, simply because it was so easy to implement. This > >> has > >> > led to innumerable errors, vulnerabilities, and system crashes, which > >> have > >> > probably caused a billion dollars of pain and damage in the last forty > >> > years. > >> > > >> > How about we stop passing nulls around as method arguments, field > >> values, > >> > return values, etc and use Optional instead? Benefits: > >> > - No more NPEs > >> > - Better documentation through code > >> > - Less mistakes > >> > > >> > I'm not suggesting we go rewrite everything, but rather just starting > to > >> > only return and accept Optionals in methods/constructors/etc. > >> > > >> > Jad. > >> > > >> > -- > >> > Jad Naous > >> > Imply | VP R&D > >> > 650-521-3425 > >> > jad.na...@imply.io > >> > > >> > > > > > > -- > > Jad Naous > > Imply | VP R&D > > 650-521-3425 > > jad.na...@imply.io > > > > > -- > Jad Naous > Imply | VP R&D > 650-521-3425 > jad.na...@imply.io >
