Optional != @Nullable

[Sam Pullara]

If that is what you think it is, then I am definitely against it.
Introducing a runtime cost for documentation seems like a bad idea to me.
Especially since we aren't planning on changing the entire JDK library to
return Optional<T> when they may return null. At this point in Java's life
I am willing to concede that null exists and having a better way of dealing
with it is great but it should deal with it in the context of current
libraries. The transitivity,  will stop as soon as you encounter an API
that doesn't support Optional as you'll need to be explicit. Don't
@Nullable/@NotNull have similar transitivity?

Sam

On Sun, Sep 30, 2012 at 3:36 PM, Jed Wesley-Smith <jed.wesleysmith at gmail.com
> wrote:

> 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
>>
>>
>