>
> > 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, although it doesn't seem to me too much to ask to have a logic
block:
>
> > 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 Javadoc of the "...FractionFormat" classes is also badly out-of-sync
> since most methods refer to "complex" (?), witnessing the extremely low
> usage.
>
> Best regards,
> Gilles
>
> >
> > 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
> >
>
> [1] Application developers can customize at will from the return values of
> "getNumerator()" and "getDenominator()" methods.
>
> > On Sat, Jan 26, 2019 at 12:11 PM Gilles Sadowski <gillese...@gmail.com>
> > wrote:
> >
> > > Le sam. 26 janv. 2019 à 17:24, Gary Gregory <garydgreg...@gmail.com> a
> > > écrit :
> > > >
> > > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <
> gillese...@gmail.com>
> > > > wrote:
> > > >
> > > > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory <
> garydgreg...@gmail.com> 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 <
> > > gillese...@gmail.com>
> > > > > > 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: dev-unsubscr...@commons.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
