On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
On Sat, Jan 28, 2017 at 7:00 PM, Gilles
<gil...@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. ;-)
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
