Re: [Numbers] Formatting classes

2019-01-31 Thread Gilles Sadowski
Hi Eric. Le jeu. 31 janv. 2019 à 22:04, Eric Barnhill a écrit : > > Please ignore previous post which was sent by accident. > > > > > > > Le mar. 29 janv. 2019 à 00:14, Eric Barnhill a > > écrit : > > > > > > Fraction already has a toString() method which should cover VALJO > > concerns > > > by

Re: [Numbers] Formatting classes

2019-01-31 Thread Eric Barnhill
Please ignore previous post which was sent by accident. > > Le mar. 29 janv. 2019 à 00:14, Eric Barnhill 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 (suppres

Re: [Numbers] Formatting classes

2019-01-31 Thread Eric Barnhill
> > > 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 represent

Re: [Numbers] Formatting classes

2019-01-29 Thread Gilles Sadowski
Hello. Le mar. 29 janv. 2019 à 00:14, Eric Barnhill 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 ve

Re: [Numbers] Formatting classes

2019-01-28 Thread Eric Barnhill
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 ha

Re: [Numbers] Formatting classes

2019-01-26 Thread Gilles Sadowski
Le sam. 26 janv. 2019 à 17:24, Gary Gregory a écrit : > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski > wrote: > > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory a > > écrit : > > > > > > Are we talking about formatting [numbers] specific classes or JRE > > classes? > > > > They are classes

Re: [Numbers] Formatting classes

2019-01-26 Thread Rob Tompkins
> On Jan 26, 2019, at 11:24 AM, Gary Gregory wrote: > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski > wrote: > >> Le sam. 26 janv. 2019 à 14:01, Gary Gregory a >> écrit : >>> >>> Are we talking about formatting [numbers] specific classes or JRE >> classes? >> >> They are classes that

Re: [Numbers] Formatting classes

2019-01-26 Thread Gary Gregory
On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski wrote: > Le sam. 26 janv. 2019 à 14:01, Gary Gregory 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], > (specificall

Re: [Numbers] Formatting classes

2019-01-26 Thread Gilles Sadowski
Le sam. 26 janv. 2019 à 14:01, Gary Gregory 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). The classe

Re: [Numbers] Formatting classes

2019-01-26 Thread Gary Gregory
Are we talking about formatting [numbers] specific classes or JRE classes? Gary On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski 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 >

[Numbers] Formatting classes

2019-01-26 Thread Gilles Sadowski
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