commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Numbers] Parsing and formatting classes
Date Sun, 29 Jan 2017 22:29:10 GMT
On Sun, 29 Jan 2017 17:15:02 +0100, Gilles wrote:
> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>> On Sat, Jan 28, 2017 at 7:00 PM, Gilles 
>> <>
>> wrote:
>>> Hi.
>>> On Sat, 28 Jan 2017 14:38:21 -0500, Raymond DeCampo wrote:
>>>> [...]
>>>>> Now, for the contents of the "fraction" module.
>>>>> (1)
>>>>> My main current concern is the formatting-related classes; as for
>>>>> "complex", I think that
>>>>>  1. formatting (and I/O) is out of scope, and
>>>>>  2. the implementation were problematic in CM already.
>>>>> Hence, I'd prefer to drop support altogether.[1]
>>>>> I see your point of view, but allow me to play devil's advocate.  
>>>>> It
>>>> seems
>>>> natural to create the formatter for a new object, in particular a 
>>>> number
>>>> type, close to the type itself.  Making new objects and expecting 
>>>> another
>>>> project to implement the formatting seems like what economists 
>>>> call an
>>>> externality.  I suppose it really depends how everyone maintaining 
>>>> text
>>>> would feel about it.  I am somewhat concerned about how the 
>>>> release cycle
>>>> would work, in particular for the initial released, where text 
>>>> would have
>>>> to wait for a release of numbers before including the formatting 
>>>> and then
>>>> users would not have formatting until the next release of text.
>>>> That said if the people maintaining text agree I have no 
>>>> objection.
>>> [Text] is also a new component. It is not unthinkable that its 
>>> scope
>>> can encompass flexible formatting of such things as "fractions".
>> At the risk of raising a sore subject, wasn't the expectations of 
>> third
>> parties that someone else maintain code for them part of the impetus 
>> for
>> the current effort?
> I'm not sure I understand what you wrote here.
>> So shouldn't we get buy-in from the commons-text team
>> before we make a decision?
> My proposal does not imply that someone else should implement
> the code.
> For example, if you feel confident that the input parsing and
> output formatting classes are useful and well implemented, you
> can start a discussion on this ML (with subject prefix [Text]),
> to inquire about objections to moving them to [Text].
> It seems that it was informally agreed that [Text] is a somewhat
> higher level component, i.e. that it can have runtime dependencies.
>>> As suggested, someone having a clear idea of what would be the use
>>> cases for formatting fraction, complex, and the likes, can create a
>>> new "commons-text-math-formatting" module (that would depend on the
>>> necessary modules from [Numbers]).
>>> From my experience with them, the formatting class from [Math] are
>>> not worth keeping.
>>> A lot of other codes should IMHO be given higher priority.
>>> My point is that, generally, people using "fraction" can do with 
>>> the
>>> constructors (to input data) and the accessors (to read result).
>>> Moreover, developers of "fraction" usually would not want to spend
>>> inordinate amounts of time to satisfy new formatting requests (that
>>> tend to translate into hundreds of lines of code, cf. CM).
>> The existence of some formats shouldn't result in an obligation to 
>> support
>> whatever formats are requested.
> Certainly.
> But it is easier to justify as "out of scope", rather than "we don't
> care about format X".
> Then if someone comes up with a good library that can handle the
> "Commons Numbers" types, our incomplete code will become obsolete,
> and any work put in it will have been useless. The question is:
> Are there _currently_ any use-cases for it?
> If there aren't, please let's not rush to add it to the new 
> component.

Question about the parsing classes.

Why isn't there a
   public static Fraction parseFraction(String s)
method (similar to the JDK's subclasses of "java.lang.Number").

Why does method
   public Fraction parse(final String source)
in "FractionFormat" throw a subclass of "ArithmeticException" while
"parse" methods of the JDK's "Number" class throw 
(a subclass of "IllegalArgumentException")?

Why does the parsing depend on "Locale"? ["Number" subclasses do not.]

Why use "StringBuffer"?

Why do several of the Javadoc comments in "FractionFormat" mention
"complex format"?

The more we look into these old classes ("@since 1.1"), the more we'll
find that they should have been deprecated, and that probably nobody
uses them (or we should have gotten some remarks about the above).


>>> The formatting code itself is not part of the concept, and so IMO
>>> effectively out of scope.
>>> There is no more sense to output "ugly" ASCII than there would be
>>> to generate any other output formats that would be more suited to
>>> represent mathematical concept (e.g. LaTeX).
>>> For logging and debugging purpose, "toString" should be quite fine.
>> I imagine that the greater value is in the parsing portion of the 
>> format
>> classes, not the output portion.
> I do not have enough imagination. ;-)
> Regards,
> Gilles

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message