Review Request: 8004201: add reducers to primitive type wrappers

[Akhil Arora]

http://cr.openjdk.java.net/~akhil/8004201.3/webrev/

- removed these operators on Byte and Short
- javadoc improvements based on CCC review

On 12/10/2012 03:45 PM, Akhil Arora wrote:
> http://cr.openjdk.java.net/~akhil/8004201.2/webrev/
>
> - replaced "Suitable for conversion as a method reference to functional
> interfaces such as ..." with @see java.util.function.BinaryOperator
>
> - javadoc - replaced 'a <type> argument'/'another <type> argument' with
> 'the first operand'/'the second operand'
>
> - did not widen return types - widening the return type makes these
> methods unusable as reducers, since BinaryOperator is declared
>    T operate(T left, T right)
>
> Thanks
>
> On 12/05/2012 03:44 PM, Joseph Darcy wrote:
>> Akhil,
>>
>> In javadoc like this
>>
>> 298      * as {@code BinaryOperator&lt;Boolean&gt;}.
>>
>> you don't have to use "&lt;" and the like inside {@code}; please
>> change to
>>
>> 298      * as {@code BinaryOperator<Boolean>}.
>>
>> As a general comment, if the operations for primitive type Foo are put
>> into java.lang.Foo, then the type of the operation needs to be
>> explicitly represented in the expression calling the method (unless
>> static imports are used, etc.).  Therefore, I suggest putting these sort
>> of static methods all into one class to allow overloading to do its
>> thing (java.lang.Operators?).  Also, for methods like sum, I think it is
>> worth considering returning a larger type than the operands to avoid
>> problems from integer or floating-point overflow. For example, sum on
>> byte and short would return int, sun on int would return long, etc.
>>
>> As an aside, to get a numerically robust result, the summation logic
>> over a set of doubles needs to be more than just a set of raw double
>> additions, but that can be tackled later.
>>
>> Cheers,
>>
>> -Joe
>>
>>
>> On 12/5/2012 1:27 PM, Akhil Arora wrote:
>>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
>>>
>>> - delegate to Math.min/max for int/long/float/double
>>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
>>> - removed Character variants of min/max/sum
>>>
>>> On 12/02/2012 05:50 PM, David Holmes wrote:
>>>> Hi Akhil,
>>>>
>>>> Is it really necessary/desirable to flag all of these as " Suitable for
>>>> conversion as a method reference to functional interfaces such as
>>>> ..." ?
>>> Not necessary, but it does provide a hint as to their intended use to a
>>> casual browser of these docs.
>>>
>>>> This style:
>>>>
>>>> +     * @param   a   a boolean argument.
>>>> +     * @param   b   another boolean argument.
>>>>
>>>> is at odds with the style used elsewhere for new Functional APIs, and
>>>> with the style of other methods in these classes. Can we just use
>>>> "first
>>>> operand" and "second operand" for all of these?
>>> It is consistent with Math.min/max, which use the a/b style. Since these
>>> methods are not in one of the functional package, is'nt it better to
>>> stick to the local style?
>>>
>>>> Character.sum does not make sense to me. Who adds together characters?
>>>> I'm not even sure min and max are worth supporting for Character.
>>> Good point - removed these methods for Character.
>>>
>>>> I disagree with other suggestions to use the Math functions for
>>>> float/double. I think all these methods should use the underlying
>>>> primitive operator regardless of type.
>>> Are you disagreeing only for float/double or for int/long also? Can you
>>> provide more information as to why you disagree?
>>>
>>> Thanks
>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>>>>> Hi
>>>>>
>>>>> Requesting review for some basic functionality related to lambdas -
>>>>>
>>>>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>>>>> Short, Integer, Long, Float, Double and Character so as to be able to
>>>>> use them as reducers in lambda expressions. Add and, or, xor
>>>>> methods to
>>>>> Boolean.
>>>>>
>>>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201
>>>>>
>>>>> Thanks
>>>
>>
>