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 (Was: Further work on NUMBERS-6)
Date Sun, 29 Jan 2017 16:15:02 GMT
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.

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


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

View raw message