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.
