DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29294>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29294 [lang][PATCH] lang.math.Fraction class deficiencies ------- Additional Comments From [EMAIL PROTECTED] 2004-05-31 10:07 ------- I've implemented option (b) from the previous comment. Fraction is now completely backwards-compatible, but getFraction and getReducedFraction have been deprecated in favor of a new 'valueOf' method (which is what the JDK subclasses of Number use, anyway). If you avoid getFraction(), you will never touch the backwards-compatibility code and your fractions will always be reduced. Serialization is compatible, too. Added a new test suite, FractionTest2. FractionTest now tests only the 'backwards-compatible' interface (and you'll notice that the diff is smaller and the results of no existing tests have changed). FractionTest2 uses 'valueOf' to test the 'modern' interface. Diffing FractionTest against FractionTest2 gives a reasonably straight-forward diff which shows what behavior is changed by the new interface: basically fractions are always reduced, hashCode() and equals() reflect numerical equality, and fewer computations overflow. I hope this will address the backwards-compatibility concerns in a way that preserves a clean interface for new users. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
