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 00:13:13 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 00:13 -------
It has been mentioned that perhaps Fraction (and BigFraction) belong in the
'math' package, instead of 'lang'.  But also that a version of Fraction which
fixed just the most glaring bugs might remain in 'lang' (hopefully deprecated).
 I responded on the commons-dev mailing list as follows:
----
*Two* versions of the fraction class?  One broken, one not?  I don't understand
this.  Is there really an existing user complaining that we're taking away the
"2/4 != 1/2" behavior?
                                                                                
It seems to me, at least, that it makes sense to apply the change and wait for
users to complain (that's what alpha, beta, and rc releases are for) before
preserving "surprising" behavior.  It's not like the patch can't be a) reverted,
or b) hacked to preserve unreduced fractions for abs(), getFraction(), pow(),
equals(), and hashCode() [but not other methods] later, if it seems to be an issue.
                                                                                
For option b) I'd suggest a private subclass returned by getFraction() which
overrode just abs(), pow(), equals(), and hashCode().  Then
Fraction.getFraction() would be deprecated and users would be strongly
encouraged to use Fraction.getReducedFraction() instead, which ensures that they
will never touch the 'backwards compatibility' code.

[Note that both abs() and pow() will always return a reduced fraction given a
reduced fraction, as a little thinking should convince you.]
                                                                                
But again, this seems like a long way to bend over backwards for users-who-care
who have not yet been shown to exist. [google didn't help me find any.]

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