This is good feedback, but why are you sending it here instead of lambda-dev?
-- Cédric On Fri, Nov 16, 2012 at 9:23 AM, Simon Ochsenreither < simon.ochsenreit...@gmail.com> wrote: > After basically everyone on lambda-dev/lambda-libs-spec-experts tried to > tell Goetz to call functions functions, I looked looked into the > implementation and I guess, I can understand their concern now: > > java.util.function: > ------------------- > BiBlock.java > BiFunction.java > BiPredicate.java > BinaryOperator.java > Block.java > Combiner.java > DoubleBinaryOperator.java > DoubleFunction.java > DoubleUnaryOperator.java > FlatMapper.java > Function.java > Functions.java > IntBinaryOperator.java > IntFunction.java > IntSupplier.java > IntUnaryOperator.java > LongBinaryOperator.java > LongFunction.java > LongUnaryOperator.java > Predicate.java > Predicates.java > Supplier.java > UnaryOperator.java > > ( > http://hg.openjdk.java.net/lambda/lambda/jdk/file/ba27872c81f8/src/share/classes/java/util/stream/primitive/ > ) > > Not only that the naming seems to be all over the place and hard to > remember (yes, names actually matter, read on ...), the manual > specialization looks extremely scary. Why are they trying to solve a > JVM/JIT problem (assuming Generics will never be improved) in a library in > such an arcane and error-prone way (why not use at least M4 macros like in > *Buffer)? > > Another weird thing is that these specializations are NOT compatible with > their more general implementation. So everywhere, where you'd want to > define a lambda, a developer now needs to decide if you assign it to e. g. > Function<Integer,Integer> or to IntFunction<Integer>. Even worse, there > seems to be no right or wrong (as soon as your code is slightly generic on > its input, you can't use the specialized functions anymore). > > If a developer used the first way and some library uses the second? Bad > luck. > If a developer used the second way and some library uses the first? Bad > luck, too. > > Also scary: > http://hg.openjdk.java.net/lambda/lambda/jdk/file/ba27872c81f8/src/share/classes/java/util/stream/primitive/and > (to a lesser amount) > http://hg.openjdk.java.net/lambda/lambda/jdk/file/ba27872c81f8/src/share/classes/java/util/stream/op/ > . > > Keep in mind, that classes are currently only specialized to int! So if > they keep this approach, the amount of classes in primitive will quadruple > (int, long, float, double). > > I really hope that Oracle comes up with an better approach, otherwise Java > 8 will be the language will give both OOP *and* FP a bad name ... > > -- > 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/-/h3N9iR664JgJ. > > 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. > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. 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.
