Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces

[David Holmes]

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
>