Error bothers me too, I'll discuss that with the others. Thanks for mentioning it.
On Wed, Oct 24, 2012 at 2:37 PM, clay <[email protected]> wrote: > It is important to have a good official standard JDK implementation, not a > poor JDK version and a bunch of optional add-in third party replacements and > support libraries. > > Improving Functional Java is good and accessible to us mere programmers > (fixing fj's weirdness about throwing Error rather than an Exception > subclass would be nice), but it is distantly inferior to having a good JDK > version. The community of people who care about this should do a better job > of convincing the JDK people to do the right thing while this is still in > development, before JDK 8 is set in stone. > > On Wednesday, October 24, 2012 12:13:13 PM UTC-5, Ricky Clarkson wrote: >> >> 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 >>>> >>>> Also, consider that Optional.asSet(), Iterables.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 view this discussion on the web visit > https://groups.google.com/d/msg/javaposse/-/AVs8YepKaOoJ. > > 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.
