Optional -> OptionalResult

[Peter Levart]

On 06/05/2013 11:20 AM, Stephen Colebourne wrote:
> No, I'd just use null for something that is optional. It what Java has
> used for donkeys years, what works with the JavaBean spec and doesn't
> require extra thinking. What it does require is documenting whether
> the parameter/return value can be null or not, but that should be done
> anyway.
I concur!

When Optional was first introduced to Stream API, I thought that it's 
intention was to actually enable the API to be non-ambiguous in places 
like Stream.findFirst(), etc. In a sense that Map.get(key) method is 
ambiguous (null return can mean two things)...

But as current Java Optional can not be a container for null value, 
Streams containing null elements will throw NPE when invoking methods 
like findFirst() on them. So if the decision was to not fully support 
null transparency in Stream API the ambiguity of null return from 
findFirst() and such could be solved in exactly the same way as it is 
solved now, but without introducing Optional class:
- null return means no such element
- if null is encountered as element of the stream, findFirst() and such 
then throw NPE.

I'm not talking about "how nice" the code looks when using such API but 
"what can" be accomplished by using it. Of course with language support 
like ?. and ?: the code would could look much nicer even without Optional.

Regards, Peter