On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
On Sun, Jan 29, 2017 at 11:15 AM, Gilles
<gil...@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
<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. ;-)
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
