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

[Jack Moxley]

Whatever happened to the elvis operator solution from project coin, surely that solves the majority of issues Optional was meant to solve anyway, without the headache of type-mix mud clutering up the code.

http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html

  _____  

From: Remi Forax [mailto:forax at univ-mlv.fr]
To: Jed Wesley-Smith [mailto:jed.wesleysmith at gmail.com]
Cc: lambda-libs-spec-experts at openjdk.java.net [mailto:lambda-libs-spec-experts at openjdk.java.net], lambda-dev at openjdk.java.net [mailto:lambda-dev at openjdk.java.net], core-libs-dev at openjdk.java.net [mailto:core-libs-dev at openjdk.java.net]
Sent: Wed, 06 Mar 2013 11:58:43 +0000
Subject: Re: RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt,  OptionalLong

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