Review Request: 8004201: add reducers to primitive type wrappers

[Stephen Colebourne]

Can the sum() static method be written as a plus instance methods?

public Integer plus(Integer other) {
  return value + other;
}

This would be more useful outside of Project Lambda, and as I
understand it, can still be used as a method reference taking two
Integers and returning one Integer.

I guess sum() could stay for avoiding boxing?


Separately, there is no "subtract" method (static or instance), or
"negate" method (static or instance), or multipliedBy/dividedBy etc.
Providing some but not all of the basic primitives is something the
JDK has a habit of doing... it would be nice to get the complete set
this time.

Stephen



On 11 December 2012 19:54, Akhil Arora <akhil.arora at oracle.com> wrote:
> 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
>>>>
>>>>
>>>
>>
>