Review Request: 8004201: add reducers to primitive type wrappers

[Remi Forax]

On 12/06/2012 06:35 PM, Brian Goetz wrote:
> 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.

I think that rule for method references are strong enough (unlike lambda 
you don't have to guess the type of the formal parameter) to work here,
but we should not play with the devil.

Rémi

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