Well, in any case, I can let you know that fj.data.Option will continue to work in Java 8 and that it will be lambda-friendly. I am porting it to Java 8 in a branch (rickyclarkson/functionaljava branch java8 on github).
If you want to help, please make it buildable in sbt or make the tests buildable in maven. When sbt hands the lambdaified Java sources to scalac, scalac barfs, and the option for skipping that step in sbt doesn't seem to do anything. I haven't tried to get the tests building with maven yet. I'm not sure whether to do that or port them from Scala to Java. I'll also be (depending on what other FJ users say) looking at dropping some types/methods if the core implements them well enough. A number of curried methods in FJ could be replaced with method references in Java 8, for instance. The main difficulty is that FJ tends to use abstract classes instead of interfaces, and lambdas can only target interfaces. This means breaking API changes unless they look at introducing static defender methods. On Oct 24, 2012 2:02 PM, "clay" <[email protected]> wrote: > The Guava teams reasons may be present(), but they are mostly hidden(), > and secret(). The Guava team rep, Kevin Bourrillion, flat out said that > they debated internally, and they are not explaining or open to further > discussions, and sorry if you don't like it: > > "Optional was the cause of possibly the single greatest conflagration on > the internal Java libraries discussion lists ever. Everyone, but everyone > has a strong opinion on this thing. I want to acknowledge the really > awkward position it puts you all in to be presented with the result of all > that churn without having the visibility into how it got that way. Your > fresh perspective on it is still beneficial, but often we're going to have > to say... "sorry, we did think about this fully already, and decided > against it" and I'm sorry if that's a drag." > > And the limited reasons they did give are terrible: > > "Implementing Iterable directly, so as to allow "for" loops directly over > it, might just produce misleading code. When I see a for loop, I expect > it's because I'm, you know, looping. "If present, get" is probably just a > clearer idiom." > > Option is a 0-1 collection and a for loop does "loop" over that 0-1 times. > This is a terrible reason. > > "One of the biggest misconceptions out there about Guava is that we are > actually trying to make functional programming in Java awesome. We have no > such delusions, and aren't FP kool-aid-drinkers. We have just added > certain things as we have needed them. But FP-like programming in Java > will only become palatable in JDK 8,..." > > So, the Guava guys have a derisive "don't drink the kool-aid" attitude > towards functional programming. But, the Java guys are supposedly trying to > make JDK 8 functional friendly, which is why it's problematic that the > official JDK 8 Optiona implementation isn't adding flatMap or iteration > support. > > Sure, you can defend any bad design as a polite difference of opinion. > First, I am offended because I care about Java and don't want the > functional support in JDK 8 to be a joke that is rightfully snickered at. > Secondly, the more objective measure I can point to is that people who want > an Option class, but don't want flatMap + collection behavior and for > iteration are in the minority. Of course, there are many who simply don't > want Option at all, and that seems more reasonable; let the functional > people go to Scala and keep Java as the more entry level language, like the > way Microsoft added Option to F# but kept it out of C#. Even Microsoft > added proper flatMap and iteration support to F# Option. > > > On Wednesday, October 24, 2012 7:57:18 AM UTC-5, Christian Gruber wrote: >> >> Actually, it's occasionally asked for, and the discussion is robust. >> >> https://groups.google.com/**forum/m/#!msg/guava-discuss/** >> JVgYWq6VU4c/GbdqVcvr610J<https://groups.google.com/forum/m/#!msg/guava-discuss/JVgYWq6VU4c/GbdqVcvr610J> >> >> Also, consider that Optional.asSet(), Iterabl**es.transform(), Iterables. >> **filter() are the guava idioms or what you're talking about. No, >> they're not exactly like scala. Yes, a LOT of churn happened internally >> and externally before arriving at this place. >> >> The reasons and resulting API may not be to your preferences, but its not >> Optional<Rationale> nor even @Nullable Rationall r. The reasons are >> present(). You just disagree. And reasonable, professional adults can >> sometimes do that. >> >> Regards, >> Christian >> Sent from my iPhone. >> >> On Oct 24, 2012, at 3:04, clay <[email protected]> wrote: >> >> I read that map/flatMap are commonly requested features for Guava >> Optional, but the Guava team just dismisses the requests without apparent >> reason. >> >> -- > 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/-/J3_hJuQGXPQJ. > 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. > -- 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.
