Hi Mike,
Minor typos and inconsistencies:
DoubleBinaryOperator.java
28 * Combines two {@code double} operands producing an {@code double}
result.
an -> a
51 * @param rightvalue used as the right operand
Need space after right
52 * @return result value of the operation
"result value" doesn't read right - just "@return the result of ..." -
as for BinaryOperator.operate
General consistency: all like methods in a family of interfaces should
use the same wording. Eg BinaryOperator.operate says "upon the provided
operands" whereas DoubleBinaryOperator.* says "upon the operands". Ditto
across families ie UnaryOperator and BinaryOperator should use
consistent terminology for operands and results.
---
DoubleBlock.java:
31 * @param <T> The type of input objects to {@code accept}.
DoubleBlock is not a generic type. (Surely this should be generating a
javadoc warning?)
---
DoubleFunction.java
32 * @param <T> the type of input objects to the {@code apply} operation.
You now potentially have multiple operation methods, and T refers to the
input of all of them.
----
General consistency comments across everything:
- Use of operand versus provided operand versus input value etc
- Use of result vs computed result vs result value vs output etc
---
Function.java
33 * @param <R> the type of output objects from {@code apply} operation.
from -> from the
43 * @param t the input object to be to which the function will
be applied.
delete "to be" ? Or else re-word.
---
UnaryOperator.java
28 * Operator on a single operand.
Operator -> operate ?
30 * @param <T> the type of input objects to {@code operate} and of
the result.
objects -> object
---
Cheers,
David
On 20/11/2012 2:55 PM, Mike Duigou wrote:
I have posted another revision at
http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/
This version contains some method remaining in the {I|L|D}UnaryOperation and
{I|L|D}BinaryOperator and a few Javadoc fixes.
The package javadoc ie. package-info.java, is known to be a weak point right
now. We're still debating what must be said here and what would be better said
attached to the APIs which consume these functional interfaces.
We don't anticipate many (any?) further changes to the naming before commit at
this point.
Mike
On Nov 13 2012, at 17:19 , Mike Duigou wrote:
Hello all;
I apologize for the quick turnaround from the second review request [1] but
I've updated the webrev again:
http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/
Blame a busy Paul Sandoz who his making significant progress on the primitive
specializations implementation. ;-)
This update includes:
- Block.apply renamed to Block.accept
- {Int|Long|Double}Block specializations added.
- Commented out "extends Combiner<T,T,T>" in BinaryOperator was removed for now
since Combiner is out of scope for this review.
- The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now
show commented out extends of the generic version along with commented out
default methods. This change will not be part of the commit but is meant to
show where the implementation will be going.
- The {Int|Long|Double} specializations of Supplier now extend generic
Supplier, have getAs{Int|Long|Double} as their abstract method and provide a
commented out default get() method to satisfy the need for a get implementation.
- The {Int|Long|Double} specializations of Function now extend generic
Function, have applyAs{Int|Long|Double} as their abstract method and provide a
commented out default apply() method to satisfy the need for an apply
implementation.
Mike
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html
