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

[Howard Lovatt]

Couple of quick comments:

1. I think the naming is inconsistent between class and method, e.g. IntFunction has an applyAsInt method. Why not either IntFunction and intApply or FunctionAsInt and applyAsInt?

2. It would be good to have a description of the stream library, perhaps an expanded for of Brian's State of Streams document referenced throughout the API like the Collections API has. 

Sent from my iPad

On 20/11/2012, at 5:31 PM, David Holmes <david.holmes at oracle.com> wrote:

> 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
>