> > 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. >
I have already seen that email but It doesn't clarify my doubts at all. I wonder how it clarifies yours. 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." > This is just false. The only "essential nature" of an Option is to model a value that could be potentially absent. I don't know any other shared and widely accepted viewpoint. Do you? > 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. > Ok , so this what a Java8 Optional is NOT. But what IS it? > (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. > I am not asking to turn Java into Scala. What I am asking is: either provide an acceptable Optional implementation with the features that a functional programmer expects to find in it or simply give up with it. Moreover if the value of flatMap without the linguistic support mentioned by Brian is so greatly decreased why they added it to the Iterable interface without any objection? > On a purely practical note, the discussions surrounding Optional have > exceeded its design budget by several orders of magnitude. > True, but this has been caused only by the irrational choice of implementing it in a so "unconventional" way. If they developed the Optional as expected by the average functional programmer there won't be any discussion at all. There are no multiple viewpoints: an Option is an Option as widely accepted by the community of functional programmers. And saying that you are not turning Java in a functional language while you're adding lambda expression to it, is just silly. > We've carefully considered the considerable input we've received, spent no > small amount of time thinking about it, > No, you don't. > and have concluded that the current design center is the right one for the > current time. > No, it is not. > 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. > Mail ended! Ok, so where is the explanation of what an Optional is. I still don't see any. Mario -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/Z4bnBRUhq0UJ. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
