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 20040614 17:19 
Mailing list commentary:

Date: Tue, 8 Jun 2004 22:08:48 0400 (EDT)
From: Henri Yandell
> Phil Steitz wrote:
> > One thing that we might want to consider, given the magnitude of the
> > changes, is deprecating this in [lang] and moving it to [math]. That
> > way, among other things, the (better) continued fraction
> > implementation in [math] could be used in getFraction(double). The
> > improved gcd and checked integer arithmetic methods in the patch might
> > also make good additions to o.a.c.math.MathUtils.
+1 to this too. Deprecate in 2.1, remove in 3.0.
I think Fraction will be better served by being in Math where it can
combine with other code, than in Lang. I don't think there are many
examples where Fraction will be of use but not other Math things, only an
educational piece of code where majority of the maths in Math is too
complex.
Hen

Date: Wed, 9 Jun 2004 21:38:38 +0100
From: Stephen Colebourne
From: "Henri Yandell" <bayard@generationjava.com>
> I think Fraction will be better served by being in Math where it can
> combine with other code, than in Lang. I don't think there are many
> examples where Fraction will be of use but not other Math things, only an
> educational piece of code where majority of the maths in Math is too
> complex.
I agree that [math] is the best home for solving these problems fully,
however I can't help feel that Fraction is a class that should be in the JDK
and fits in [lang] scope. So, [lang] gets a (fixed) Fraction class, while
[math] gets Ratio/BigFraction/Fraction/... whatever is appropriate.
Stephen

Date: Wed, 09 Jun 2004 16:59:46 0400
From: Mark R. Diggory
Stephen Colebourne wrote:
>I agree that [math] is the best home for solving these problems fully,
>however I can't help feel that Fraction is a class that should be in the JDK
>and fits in [lang] scope. So, [lang] gets a (fixed) Fraction class, while
>[math] gets Ratio/BigFraction/Fraction/... whatever is appropriate.
This makes sense only if there is always a 1 to 1 mapping between
o.a.c.lang and java.lang, meaning, somehow the contents we have in our
lang represent things we would like to see in java.lang someday (whether
truly plausable or not). I'm not convinced this is possible, there are
too much content in java.lang that overlaps with other commons subprojects.
As well, I consider "java.lang" is really a poorly named and poorly
defined package in the first place, a kind of "catchall" for initial
object hierarchy of Java (similarly, java.util is a poorly named
"catchall" for the initial datastructures and collections) . I think
there should have been a java.math package that housed Math, Number ...
plus java.util.Random .... This would have been the home for something
like Fraction in my little fantasy world.
Either way, I think Math would be glad to support Fraction in the Math
subproject if concensus proves it wanted.
And don't mis[i]nterpret my opinion, +1 on patching it even if it stays
where it is.
Mark

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
