RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong

[Jed Wesley-Smith]

There is no need for an Option container to show how nested collections may be misused, you could just as easily show an example of a List<List<List<T>>> that is isomorphic to a flattened Iterable<T> . I'd simply point to the utility of the monadic bind or flatMap function!

There are several reasons why Option types provide serious usability improvements over null, notwithstanding annotation support. The first is that the type-system prevents misuse (modulo unsafe API), and the second is that it allows operations that produce optional results to be sequenced easily without if checks. For mor information see previous posts on Optional forming a Monad.

cheers,
jed.

On 06/03/2013, at 10:58 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 03/06/2013 11:54 AM, Jed Wesley-Smith wrote:
>> Really, this is a lot of fuss over nothing.
>> 
>> There is actually no fundamental difference between Scala's Option, Guava's Optional, Fugue's Option, Java's Optional and Haskell's Maybe – they are modelling the same thing, the possibility of a value not being present.
>> 
>> The fact that there may be minor differences in api or semantics around whether null is a legal value are minor in the scheme of things (and yes, null is a pretty stupid legal value of a Some IMHO).
>> 
>> Stephen's example is ludicrous, why have a list of optional values? You'd flatten down into just a list – and an optional list only makes sense if the enclosed list is guaranteed to be non-empty, otherwise you just return an empty list!
> 
> People like shooting their own feet.
> http://cs.calstatela.edu/wiki/index.php/Courses/CS_460/Fall_2012/Week_8/gamePlay.combat.BattleAnalysis 
> 
>> 
>> If we are going to use potential straw-men as arguments we can stall all progress. Please concentrate on the important matters, let's disavow null as a valid value and save us all a billion dollars
> 
> Also Scala Option is not the only way to solve the null problem.
> The JSR308 annotation @Nullable/@NonNull are recognized by Eclipse and IntelliJ at least.
> 
>> .
>> 
>> cheers,
>> jed.
> 
> cheers,
> Rémi
> 
>> 
>> On 06/03/2013, at 8:47 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>>> Ok, let be nuclear on this,
>>> There is no good reason to introduce Optional<T> in java.util.
>>> 
>>> It doen't work like Google's Guava Optional despite having the same
>>> name, it doesn't work like Scala's Option despite having a similar name,
>>> moreover the lambda pipeline face a similar issue with the design of
>>> collectors (see stream.collect()) but solve that similar problem with a
>>> different design, so the design of Optional is not even consistent with
>>> the rest of the stream API.
>>> 
>>> So why do we want something like Optional, we want it to be able to
>>> represent the fact that as Mike states a returning result can have no
>>> value by example Colections.emptyList().stream().findFirst() should
>>> 'return' no value.
>>> 
>>> As Stephen Colebourne said, Optional is a bad name because Scala uses
>>> Option [1] which can used in the same context, as result of a filter/map
>>> etc. but Option in Scala is a way to mask null. Given the name
>>> proximity, people will start to use Optional like Option in Scala and we
>>> will see methods returning things like Optional<List<Optional<String>>>.
>>> 
>>> Google's Guava, which is a popular library, defines a class named
>>> Optional, but allow to store null unlike the current proposed
>>> implementation, this will generate a lot of confusions and frustrations.
>>> 
>>> In fact, we don't need Optional at all, because we don't need to return
>>> a value that can represent a value or no value,
>>> the idea is that methods like findFirst should take a lambda as
>>> parameter letting the user to decide what value should be returned by
>>> findFirst if there is a value and if there is no value.
>>> So instead of
>>>   stream.findFirst().orElse(null)
>>> you will write
>>>   stream.findFirst(orNull)
>>> with orNull() defined as like that
>>>   public static <T> Optionalizer orNull() {
>>>     return (isPresent, element) -> isPresent? element: null;
>>>   }
>>> 
>>> The whole design is explained here [2] and is similar to the way
>>> Collectors are defined [3],
>>> it's basically the lambda way of thinking, instead of creating an object
>>> representing the different states resulting of a call to findFirst,
>>> findFirst takes a lambda as parameter which is fed with the states of a
>>> call.
>>> 
>>> cheers,
>>> Rémi
>>> 
>>> [1] http://www.scala-lang.org/api/current/index.html#scala.Option
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-February/001470.html
>>> [3]
>>> http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collectors.java
>>> 
>>> 
>>> On 03/04/2013 09:29 PM, Mike Duigou wrote:
>>>> Hello All;
>>>> 
>>>> This patch introduces Optional container objects to be used by the lambda streams libraries for returning results.
>>>> 
>>>> The reference Optional type, as defined, intentionally does not allow null values. null may be used with the Optional.orElse() method.
>>>> 
>>>> All of the Optional types define hashCode() and equals implementations. Use of Optional types in collections should be generally discouraged but having useful equals() and hashCode() is ever so convenient.
>>>> 
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8001642/0/webrev/
>>>> 
>>>> Mike
>>>> 
>>> 
>