Hello.
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).
> 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
