commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 29294] - [lang][PATCH] lang.math.Fraction class deficiencies
Date Mon, 31 May 2004 10:07:26 GMT
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 cananian@alumni.princeton.edu  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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message