[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [Numbers] Parsing and formatting classes
From:       Gilles <gilles () harfang ! homelinux ! org>
Date:       2017-01-31 16:27:33
Message-ID: e39c1eda3d47986e27045497512fe4de () scarlet ! be
[Download RAW message or body]

On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
> On Sun, Jan 29, 2017 at 11:15 AM, Gilles 
> <gilles@harfang.homelinux.org>
> wrote:
>
>> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>>
>>> On Sat, Jan 28, 2017 at 7:00 PM, Gilles 
>>> <gilles@harfang.homelinux.org>
>>> 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.
>>
>>
>>>> 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. ;-)
>>
>>
> Well the first use-case that comes to my mind is accepting user input 
> from
> some kind of GUI and turning it into a Fraction instance.  The second 
> would
> be extracting Fraction values from some kind of text representation, 
> e.g.
> CSV file, XML, etc.

I'd agree about parsing the output of "toString()" (i.e. a
"Locale"-independent format, similar to what the JDK does for
subclasses of "Number").

But to be able to ensure valid input from CSV, XML, etc. would
require out-of-band information that will clutter the API to no
end.

> But I think we are reaching the end of the useful phase of the 
> discussion
> so that said, I don't really have strong feelings on the matter.  I 
> would
> leave it in were it up to me but I wouldn't oppose you if you wanted 
> to
> take it out.

I want to take it out because the current code was unhelpful in the
one case where I needed it (to change the precision of the printed
value, which was about the simplest use-case). And I could not fix it
without a lot of work (to undo what the formatting instance was doing)
in order to get the same output as "toString()"!

You (and Rob) are most welcome to move the code to [Text] if you see
value in that implementation.


Regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]