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