Review Request: 8004201: add reducers to primitive type wrappers

[Brian Goetz]

This suggestion makes me nervous, because we're already asking a great 
deal of type inference.  If you say

   reduce(Operators::plus)

and there are eight versions of Operators to choose from (and add boxing 
into the mix), I think we'll see a lot more inference errors.  If the 
user says Integer::plus, the user has already told us what we want, and 
we're done.

On 12/5/2012 6:44 PM, Joseph Darcy wrote:
> 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
>>
>