Review Request: 8004201: add reducers to primitive type wrappers

[Joseph Darcy]

Akhil,

In javadoc like this

298      * as {@code BinaryOperator<Boolean>}.

you don't have to use "<" 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
>