RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries (original) (raw)
David Holmes david.holmes at oracle.com
Tue Feb 19 05:29:19 UTC 2013
- Previous message: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries
- Next message: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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 rather than IntFunction
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 the type of output objects from {@code apply} operation.
from -> from the
The *BiXXX types are not consistently documented. For example:
BiFunction has:
- @param the type of input objects provided to the {@code apply} operation.
- @param the type of input objects provided to the {@code apply} operation.
while BiPredicate has:
- @param the type of the first argument to {@code test}.
- @param 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
- Previous message: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries
- Next message: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]