Review: JDK 8 CR for Support Integer overflow (original) (raw)
Eamonn McManus eamonn at mcmanus.net
Mon Feb 6 22:47:14 UTC 2012
- Previous message: Review: JDK 8 CR for Support Integer overflow
- Next message: Using unsigned library work in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I'm with Roger on this.
Sorry, but I can't agree with this. Developers get negation of numbers wrong all the time by ignoring the special case. Its a big source of hidden bugs. Increment/decrement are replaceable by add/subtract (with less readability), but negate is not.
First of all, negate(x) certainly is replaceable by subtractExact(0, x). Secondly, the problem is more that people don't realize that -x might not be exact. If you know there's a problem then it isn't any easier for you to know that a solution is to be found in Math than to know that the problem is with MIN_VALUE.
Éamonn
On 6 February 2012 14:35, Stephen Colebourne <scolebourne at joda.org> wrote:
On 6 February 2012 21:16, Roger Riggs <Roger.Riggs at oracle.com> wrote:
* Removed the negateExact methods since they don't pull their weight in the API, simple tests for MINVALUE and MAXVALUE can be done by the developer more efficiently. Sorry, but I can't agree with this. Developers get negation of numbers wrong all the time by ignoring the special case. Its a big source of hidden bugs. Increment/decrement are replaceable by add/subtract (with less readability), but negate is not. The whole purpose of methods like this is not to say "oh they're easy for the caller to write", but to write it once accurately, well-tested, and with clear intent for code readers. Look at the methods on Objects to see that complexity of the implementation is not the deciding factor. Many, many developers will thank you for having negate, increment and decrement. Stephen
- Previous message: Review: JDK 8 CR for Support Integer overflow
- Next message: Using unsigned library work in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]