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
