Peter Levart: > I think that Optional was not m...

# random

[fellshard]

Peter Levart:

I think that Optional was not meant to be used in API-s as the type of a method parameters or as thetype of fields, but only as the return type of methods with main usage pattern of calling it's methods in a chain. For that purpose, I think the name is fine.

Explicitly not what they wanted, given the lack of flatMap.

Vitaly Davidovich:

IMHO Optional should not capture three states: non-null value, null value, and no value. This is not a common semantic (and probably isn't the type of design guidance one would give - i.e. don't use null for presence, use a Null object instead). For stream interfaces that allow impls to store null, something else should be used (StreamOptional?) to denote this - I'd leave Optional as a general class akin to Guava that only handles null vs non-null.

Also, I don't have stats to back this up but Guava is widely used now (based on my empirical observation) and people may already have a certain notion of what Optional means based on guava's definition. Adding same-named API to JDK but with different semantics seems undesirable.

Here we have reassertion of an existing library's design. Was their focus to bring Guava's concept into the fold, or was it to accomplish some specific goal that coincided with stream implementations? If the latter, why use the naming of and - implicitly - bind themselves to Guava's contract and usage?

I think the biggest problem that keeps recurring is that the 'value' null takes on different semantic values in different contexts and in different Java libraries, for better or for worse; this is a lot like SQL's issue with having multiple meanings connoted by the same NULL 'value'. The Optional type deals with exactly one form of `null`: null to represent a value that is absent. It does not account for the pragmatic cases where, say, null is used to represent a special case or is given special meaning. I'm not saying that's how these APIs should have been written, but rather that that's the way they have been written. In forcing this unnecessary contract on Optional, what they've done is enforce a conflicting view of null on any other library you interact with, instead of trusting that the user of Optional understands how they intend to use it. No matter how you slice it, it simply doesn't fit the intent they repeatedly claim.