On Sat, 16 Sep 2017 14:19:04 -0400, Raymond DeCampo wrote:
[...]
So from the POV of a "Commons Numbers" developer, what is the
added value of "Field"?
[IMO none at the moment (but that could change).]
I'm not looking at it from the POV of a CN developer. I am looking
at it
from the POV of a CN user.
If "Commons Numbers" were only to be a copy from what is/was
in CM I'd have to agree that there was no point in having a
new component in the first place.
Since there are no users right now, it seems reasonable to
me that the KISS principle should apply.
I believe this is covered in the following
paragraph you quoted.
It is a nice feature, but as with any feature implemented on
top of a more basic utility, we should first look for a solution
that is compatible with the upstream dependency.
Since Java is strongly typed and does not support duck typing
without
resorting to reflection gymnastics, there is currently no way to
write an
algorithm using e.g. the add() method which could be applied to
o.a.c.n.f.Fraction and o.a.c.n.c.Complex without duplication,
reflection
or
pointless wrapper extensions.
You may be right.
But is the CM solution the best we can do, now that it is
the moment where other solutions can be explored?
[...]
To be blunt I don't agree with the approach
Which one?
so I am not about to devote
time and effort to supporting it.
You are smarter than I ever was, since I devoted a lot of time
to implement compromise decisions in CM, although I knew that
they were bad (and proven to be so later on).
You are definitely right that the wrapper approach takes a
lot of time, mainly because of the awful amount of duplication
in the CM unit tests classes.
[I spent countless hours fixing the same in the RNG code.]
I badly underestimated the task for "Fraction"/"BigFraction". :-/
I'm also not particularly interested in
arguing about it. So I have completed the portions where we have
agreement
and left the rest.
Summarizing the other issues I found while trying to eliminate
BigFraction,
Fraction and Complex from CM:
I found nine test classes which use FractionField, those would need
to be
rewritten. I imagine they could use a different Field implementation
without a great deal of difficulty.
You are quite right; the "main" code is easy to adapt.
Adapting the unit tests, however, is a nightmare (+100 errors).
And I don't understand why it had to be, since the common "Field"
interfaces should in principle have allowed to write a test base
class, with the actual types be automatically exercised through
factory subclasses.
I also found a couple of public methods in MatrixUtils that I imagine
will
need to be deleted. I don't think they would be missed but OTOH they
were
added because somebody wanted them.
What you do propose to do about the ComplexField, FractionField and
BigFractionField classes? These were part of the CM API in the last
release are is the plan to just drop them?
I'd have thought they could be modified so that under the hood,
they use the "Numbers" implementations.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
