Hi Eric. Le jeu. 31 janv. 2019 à 22:04, Eric Barnhill <ericbarnh...@gmail.com> a écrit : > > 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()
I suspect this would be wrong. The "valueOf" should be the inverse of "toString"; it won't be (IIUC) when "toString" supresses the slash. As I said, a can of worms, not worth spending so much time. > > > > > > 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. I don't know what you mean by this last sentence. "NumberFormat" is a JDK class. > 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. I repeat that the only known case (to me) is in formatting numbers in exception messages. And this CM feature (!) produces truncated output that's a total nuisance. That would not be the first example of sloppy/useless code. Without a demonstrated example of useful application, I strongly favour not introducing this code in [Numbers] (and anything that is Locale-dependent). Its current state will always be available in the repository if we need to revisit this issue later on. > So my proposed workflow is: > -- keep the toString class I'd perhaps simplify it so that a "1" denominator is kept. Not sure about the advantage/drawbacks trade-off. > -- move parse() out of the formatting classes and into the Fraction > classes (and follow above logic) > -- move the formatting classes into the NumberFormat family Same wondering as above about this last sentence. > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
