[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [Numbers] Formatting classes
From:       Eric Barnhill <ericbarnhill () gmail ! com>
Date:       2019-01-31 21:03:48
Message-ID: CAJcp7jserKDhJYykC5y7=ccNJq7d+dY34QM3M3wFehTADCEYXA () mail ! gmail ! com
[Download RAW message or body]


Please ignore previous post which was sent by accident.



>
> Le mar. 29 janv. 2019 =C3=A0 00:14, Eric Barnhill <ericbarnhill@gmail.com=
> a
> =C3=A9crit :
> >
> > Fraction already has a toString() method which should cover VALJO
> concerns
> > by representing the instance in one specific way.
>
> It has 2 different outputs (suppress the fraction bar and denominator
> when it is 1).
> Not sure that's very robust: Expecting a "/" as part of the representatio=
n
> will make parsing easier (noting that class is still missing the
> parse/valueOf
> method).
>

Good point but I think it is not too much to ask to have a logic block:
-- if contains slash: parse numerator and denominator and construct using
of()
-- if doesn't contain slash: parse as double and construct using from()



> > The FractionFormat classes allow for options beyond this such as proper
> > fractions or region-specific versions.
>
> IMO it's out of scope for a low-level component, and at least until we
> have an actual use-case.
> Locale-specific input/output is a can of worms that should be handled
> by text-oriented libraries.
> Having output (e.g. error messages) differ from locale to locale is a
> very bad idea (in a low-level component[1]), and so is the capacity (of
> a low-level component) to truncate data that might be needed by the
> caller.  [Those two things are the purpose of the "NumberFormat"
> family of classes.]
>

The AbstractFractionFormat is an extension of NumberFormat. I agree that
these classes would serve better in the NumberFormat family. However, I
would rather do that than throw away good work. I would be surprised if
these formatting classes had _not_ been designed around some reasonable use
cases.

So my proposed workflow is:
 -- keep the toString class
 -- move parse() out of the formatting classes and into the Fraction
classes (and follow above logic)
 -- move the formatting classes into the NumberFormat family


> The Javadoc of the "...FractionFormat" classes is also badly out-of-sync
> since most methods refer to "complex" (?), witnessing the extremely low
> usage.
>

I will write a ticket for this.

Eric


[prev in list] [next in list] [prev in thread] [next in thread]