Optional != @Nullable

[Jed Wesley-Smith]

The major difference isn't really about the syntax – which I think gets a
bit too much attention, its important, but it isn't the most important
thing – its about the type.

My original point is that if we return T we don't know from that whether it
is optional or not. We may have documentation or annotation to hint to us
that it is, or isn't, but the *type signature* is just T. A type of
Option<String> is undoubtedly and unambiguously optional, and we cannot
access the inner value unsafely (modulo the unsafe get() method).

In other words, Option<T> is transitive. Consider the following:

public static Option<Integer> getProperty(String name)

If I somehow try and return this:

Integer doStuff() {
  …
  return getProperty(name); // compile error, need Integer, got
Option<Integer>
}

however, with this:

public static Integer getProperty(String name)

What happens if I pass a non-existent name? You cannot tell with reading
the docs or looking at the source. Even if I annotate the method, when I
call it as above I lose that annotation, it is *not transitive*. This is
the real benefit of Option<T> and its close relative Either<X, T>.

On 1 October 2012 06:19, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> On Sun, Sep 30, 2012 at 2:54 PM, Sam Pullara <sam at sampullara.com> wrote:
>
>      static String address(InetSocketAddress sa) {
>          return elvis(elvis(sa, sa -> sa.getAddress()), ia ->
> ia.getHostAddress());
>      }
>
> compared to Jed's syntax (to be fair, assume getAddress() etc all
> return Option<> type)
>
>      static Option<String> address(Option<InetSocketAddress> sa) {
>          return
> sa.flatMap(sa->sa.getAddress()).flatMap(ia->ia.getHostAddress());
>      }
>
> there isn't much difference in wordiness between the two camps.
>
> So the real question is, returning Option<> is more strongly typed;
> but is it *too* strongly typed? Would some people find it annoying
> like C++'s const?
>
> Zhong Yu
>
>