FYI, here is Brian's summary of the situation about Optional in Java 8. Hopefully, this will provide some background on why things are the way they are.
-- Cédric ---------- Forwarded message ---------- From: Brian Goetz <[email protected]> Date: Tue, Oct 30, 2012 at 10:24 AM Subject: Re: Optional require(s) NonNull To: Roland Tepp <[email protected]> Cc: [email protected] > I am not so much concerned about how or where people start using it (this > will settle eventually by best practices) as much as I am concerned that > the Optional type in Java SDK will not deliver on the promise people who > are familiar with the concept are expecting it to deliver: The problem is with the expectations. This is a classic "blind men and elephant" problem; the thing called Optional has different "essential natures" to different viewpoints, and the problem is not that each is not valid, the problem is that we're all using the same word to describe different concepts (more precisely, assuming that the goals of the JDK team are the same as the goals of the people you condescendingly refer to as "those familiar with the concept." There is a narrow design scope of what Optional is being used for in the JDK. The current design mostly meets that; it might be extended in small ways, but the goal is NOT to create an option monad or solve the problems that the option monad is intended to solve. (Even if we did, the result would still likely not be satisfactory; without the rest of the class library following the same monadic API conventions, without higher-kinded generics to abstract over different kinds of monads, without linguistic support for flatmap in the form of the <- operator, without pattern matching, etc, etc, the value of turning Optional into a monad is greatly decreased.) Given that this is not our goal here, we're stopping where it stops adding value according to our goals. Sorry if people are upset that we're not turning Java into Scala or Haskell, but we're not. On a purely practical note, the discussions surrounding Optional have exceeded its design budget by several orders of magnitude. We've carefully considered the considerable input we've received, spent no small amount of time thinking about it, and have concluded that the current design center is the right one for the current time. What is surely meant as well-intentioned input is in fact rapidly turning into a denial-of-service attack. We could spend endless time arguing this back and forth, and there'd be no JDK 8 as a result. I'm sure no one wants that. So, let's keep our input on the subject to that which is within the design center of the current implementation, rather than trying to convince us to change the design center. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
