Fraction already has a toString() method which should cover VALJO concerns by representing the instance in one specific way.
The FractionFormat classes allow for options beyond this such as proper fractions or region-specific versions. It doesn't seem to me like it violates VALJO principles to have an auxiliary class that takes care of these alternate cases. On the contrary from a VALJO perspective it seems like a nice idea to have encapsulated them in an auxiliary class structure. Eric On Sat, Jan 26, 2019 at 12:11 PM Gilles Sadowski <[email protected]> wrote: > Le sam. 26 janv. 2019 à 17:24, Gary Gregory <[email protected]> a > écrit : > > > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <[email protected]> > > wrote: > > > > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory <[email protected]> a > > > écrit : > > > > > > > > Are we talking about formatting [numbers] specific classes or JRE > > > classes? > > > > > > They are classes that aim to customize the output from classes in > > > [Numbers], > > > (specifically, the way to display a {{Fraction}} or {{BigFraction}} > > > object). > > > > > > > Well, then that code does not belong in [text] since it requires [number] > > classes. > > Not what I meant. > People wanting custom formatting of a fraction can get the parts that > define it (i.e. numerator and denominator) and call whatever they want > (e.g. something which might be in [Text]) in order to craft a string > representation of those numbers. > Following ValJO (even if "BigFraction" is not one, strictly speaking), > we want *one* way to represent the contents of the instance. > > Regards, > Gilles > > > > > Gary > > > > > > > The classes provide accessors to the numerator and denominator which > can be > > > used by outside code to display the fraction as it wishes. > > > > > > Side note: Similar formatting classes in Commons Math are more of a > > > nuisance > > > than anything, e.g. displaying small numbers as "0" (in exception > > > messages), > > > because the default is to provide 6 decimal digits, thus discarding > > > all significant > > > information. > > > > > > Gilles > > > > > > > > > > > Gary > > > > > > > > On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski < > [email protected]> > > > > wrote: > > > > > > > > > Hi. > > > > > > > > > > In reference to the current changes in module > > > "commons-numbers-fraction" > > > > > (on the "fraction-dev"), my opinion is that the formatting classes > > > should > > > > > be > > > > > removed.[1] > > > > > At the level of a math component, it's safer to stick to a single, > > > > > locale-independent format.[2] > > > > > > > > > > Regards, > > > > > Gilles > > > > > > > > > > [1] Rationale is that pretty-printing is not the purpose of the > library > > > > > (better > > > > > leave that to [Text], or a dedicated module). > > > > > [2] There is a pending issue (NUMBERS-88) that suggests > hard-coding the > > > > > format. > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
