commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Scott Ananian" <>
Subject Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Date Mon, 31 May 2004 00:05:39 GMT
On Sun, 30 May 2004, Phil Steitz wrote:

> > The [lang] code needs to work and be reliable. However I suspect that a
> > [math] version and [lang] version may be appropriate with slightly different
> > semantics.

*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.]

TASS LA Panama overthrow hack Peking operation supercomputer anthrax
Chechnya D5 SLBM Yeltsin biowarfare Saddam Hussein postcard C4 SLBM
                         ( )

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message