RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries

[David Holmes]

Hi Mike,

In BinaryOperator.java this sentence doesn't read correctly:

+ * An operation upon two operands yielding a result. This is a 
specialization of
+ * {@code BiFunction} for the operands and the result are all being of 
the same
+ * type.

suggestions:

{@code BiFunction} for the case where the operands and the result are 
all of the same type.

{@code BiFunction} where the operands and the result are all of the same 
type.

---

DoubleUnaryOperator.java - this changed wording seems more awkward than 
the original:

      /**
-     * Returns the {@code double} result of the operation upon the
+     * Returns a {@code double} value result of the operation upon the
       * {@code double} operand.

---

Function.java

+ * @param <R> the type of result of the {@code apply} operation.

Either "the type of the result of the ...", or "the type of result from 
the ..."

---

General comment regarding specializations of Function. If we have 
Function<T, R> where R is the result type, then in the specializations 
which specialize the input type (T) then we should use R for the 
remaining type variable eg IntFunction<R> rather than IntFunction<T>

---

In LongFunction:

+     * @param l the input value

why use l as the parameter name? I presume for "long" but why? I thought 
the "i" parameter in IntFunction was so named for "input". I would much 
rather see a common parameter naming scheme being used (i, t, val, arg - 
any of these).

---

UnaryOperator.java

This sentence doesn't read right:

+ * result are of the same type. This is a specialization of {@code 
Function} for
+ * the operand and the result of the same type.

suggest:

"This is a specialization of {@code Function} for the case where the 
operand and result are of the same type."

---

package-info.java

I've flagged this elsewhere but you may not have seen it:

+ *     Predicate<String>

If we use < then we should also use >.

---

BiFunction:

+ * is the two-arity specialization of {@link Consummer}

typo: Consummer

+ * @param <R> the type of output objects from {@code apply} operation.

from -> from the

----

The *BiXXX types are not consistently documented. For example:

BiFunction has:

+ * @param <T> the type of input objects provided to the {@code apply} 
operation.
+ * @param <U> the type of input objects provided to the {@code apply} 
operation.

while BiPredicate has:

+ * @param <T> the type of the first argument to {@code test}.
+ * @param <U> the type of the second argument to {@code test}.

I prefer the BiPredicate form.

---

DoublePredicate.java

+ * Determines if the {@code long} input value matches some criteria. 
This is the
+ * {@code double}-consuming primitive type specialization of {@link 
Predicate}.

The first "long" should be "double".

---

ToIntBiFunction.java

+ * Apply a function to the input argument,

argument -> arguments

---


Aside: it would be much easier to maintain consistent style if we used a 
"template" to define the main outline of each family of interfaces and 
generated the specializations from that (similar to how we generate the 
various bytebuffer classes).

Cheers,
David
------



On 16/02/2013 6:13 AM, Mike Duigou wrote:
> Hello All;
>
> This patch introduces a number of new functional interfaces for use by the lambda libraries. Also included are some name changes following JSR-225 EG review. The new interfaces are:
>
> BiConsumer
> BiFunction
> BiPredicate
> BooleanSupplier
> DoublePredicate
> IntPredicate
> LongPredicate
> ObjDoubleConsumer
> ObjIntConsumer
> ObjLongConsumer
> ToDoubleBiFunction
> ToDoubleFunction
> ToIntBiFunction
> ToIntFunction
> ToLongBiFunction
> ToLongFunction
>
> Renames:
>
> Block -> Consumer
> BiBlock -> BiConsumer
> IntBlock -> IntConsumer
> DoubleBlock -> LongConsumer
> LongBlock -> LongConsumer
> UnaryOperator.operate -> UnaryOperator.apply
> LongUnaryOperator.operateAsLong -> LongUnaryOperator.applyAsLong
> DoubleUnaryOperator.operateAsDouble -> DoubleUnaryOperator.applyAsDouble
> IntUnaryOperator.operateAsInt -> IntUnaryOperator.applyAsInt
> LongBinaryOperator.operateAsLong -> LongBinaryOperator.applyAsLong
> DoubleBinaryOperator.operateAsDouble -> DoubleBinaryOperator.applyAsDouble
> IntBinaryOperator.operateAsInt -> IntBinaryOperator.applyAsInt
>
> All of the changes outside the java.util.function package are made to accommodate these renamings.
>
> The webrev is located at:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/webrev/
>
> and specdiff for the java.util.function package is at:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/specdiff/
>
> Thanks!
>
> Mike
>
>