[Numbers] Formatting classes

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[Numbers] Formatting classes

Gilles Sadowski-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

garydgregory
Are we talking about formatting [numbers] specific classes or JRE classes?

Gary

On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

Gilles Sadowski-2
Le sam. 26 janv. 2019 à 14:01, Gary Gregory <[hidden email]> 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 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 <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

garydgregory
On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <[hidden email]>
wrote:

> Le sam. 26 janv. 2019 à 14:01, Gary Gregory <[hidden email]> 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.

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 <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

Rob Tompkins


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

We could use the old [lang] pattern here where the number parsing/formatting lives with number as opposed to with the text utilities. If that is an insufficient pattern, then we should look at how the JDK organizes this and try to mirror them.

-Rob

>
> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

Gilles Sadowski-2
In reply to this post by garydgregory
Le sam. 26 janv. 2019 à 17:24, Gary Gregory <[hidden email]> a écrit :

>
> On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <[hidden email]>
> wrote:
>
> > Le sam. 26 janv. 2019 à 14:01, Gary Gregory <[hidden email]> 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 <[hidden email]>
> > > 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

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 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 <[hidden email]>
wrote:

> Le sam. 26 janv. 2019 à 17:24, Gary Gregory <[hidden email]> a
> écrit :
> >
> > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <[hidden email]>
> > wrote:
> >
> > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory <[hidden email]> 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 <
> [hidden email]>
> > > > 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: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

Gilles Sadowski-2
Hello.

Le mar. 29 janv. 2019 à 00:14, Eric Barnhill <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > Le sam. 26 janv. 2019 à 17:24, Gary Gregory <[hidden email]> a
> > écrit :
> > >
> > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <[hidden email]>
> > > wrote:
> > >
> > > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory <[hidden email]> 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 <
> > [hidden email]>
> > > > > 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: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

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 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 <[hidden email]>
> > wrote:
> >
> > > Le sam. 26 janv. 2019 à 17:24, Gary Gregory <[hidden email]> a
> > > écrit :
> > > >
> > > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <
> [hidden email]>
> > > > wrote:
> > > >
> > > > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory <
> [hidden email]> 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 <
> > > [hidden email]>
> > > > > > 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: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

Eric Barnhill
In reply to this post by Gilles Sadowski-2
Please ignore previous post which was sent by accident.



>
> Le mar. 29 janv. 2019 à 00:14, Eric Barnhill <[hidden email]> 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()



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

So my proposed workflow is:
 -- keep the toString class
 -- move parse() out of the formatting classes and into the Fraction
classes (and follow above logic)
 -- move the formatting classes into the NumberFormat family


> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Formatting classes

Gilles Sadowski-2
Hi Eric.

Le jeu. 31 janv. 2019 à 22:04, Eric Barnhill <[hidden email]> a écrit :

>
> Please ignore previous post which was sent by accident.
>
>
>
> >
> > Le mar. 29 janv. 2019 à 00:14, Eric Barnhill <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]