Please ignore previous post which was sent by accident.
> > Le mar. 29 janv. 2019 à 00:14, Eric Barnhill <ericbarnh...@gmail.com> a > écrit : > > > > 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 representation > 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
