[
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17743803#comment-17743803
]
Gary Lucas commented on IMAGING-358:
------------------------------------
So what you are proposing is to replace code that has been around for long
time with an alternate module. I cited concerns that the alternate approach
might not work due to the possibility of difference in implementation and rule.
You asked the reasonable question "where are the differences?" And now I
will make the reasonable observation that the onus is on you to answer that,
not me. After all, you are the one who is proposing to replace existing code.
Before the commons-number solution could be integrated into commons-imaging,
someone would have to inspect both approaches method-by-method to verify that
the results are compatible. In doing so, he might discover that the JUnit
tests in commons-imaging needed to be enhanced to pick up the edge cases (after
all, imaging is a pretty old set of code that was written before JUnit tests
had come into wide practice).
The idea of promoting code reuse is usually a good idea. But in Imaging-356,
we saw recently that changing legacy code to use an alternate API's can go
badly wrong.
Now, regarding the idea of bloat, we will never agree. And I maintain that I
have a point that cannot be dismissed out-of-hand. Commons-numbers-fraction is
only 25.7 K with 7 compiled classes. That's no big deal in a modern computing
environment. But, oh yeah, it depends on commons-number-core (25,3 K, 14
compiled classes). So now my Configuration Management team, to whom I am
answerable, has to add two new Jar files to their build. And adding a
dependency on commons-numbers will be adding multiple classes that are
unrelated to what commons-imaging does. We use a lot of commons APIs, but we
won't currently use the numbers classes.
Finally, on a less contentious topic, I did want to add that the refactoring of
the Math project into smaller pieces is an excellent idea and that you guys
have made an outstanding effort. Some years back, I went through the mental
exercise of wondering what would be involved in reorganizing math into separate
modules (a core including linear algebra? where would combinatorics go? can you
separate statistics from differential equations? how would you handle complex
numbers?). I quickly concluded that it would be a tricky job with a lot of
hard decisions and that I wasn't even going to propose it. So I do admire
what you were able to accomplish.
> "RationalNumber" class is "public"
> ----------------------------------
>
> Key: IMAGING-358
> URL: https://issues.apache.org/jira/browse/IMAGING-358
> Project: Commons Imaging
> Issue Type: Wish
> Components: imaging.common.*
> Affects Versions: 1.0-alpha2
> Reporter: Gilles Sadowski
> Priority: Major
> Labels: API, support
> Fix For: 1.0, 1.0-alpha3
>
>
> As per its Javadoc, class
> [{{RationalNumber}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/common/RationalNumber.html]
> is tuned to the requirements of the TIFF format while its name purports that
> it's a general implementation of the "fraction" concept.
> Which is it?
> Do we want that utility to be part of [Imaging]'s public API (thus eliciting
> support to application developers who might use it beyond its intended scope)?
> A dependency on [[Numbers]'s "fraction"
> module|https://commons.apache.org/proper/commons-numbers/commons-numbers-docs/apidocs/org/apache/commons/numbers/fraction/package-summary.html],
> as proposed in IMAGING-309) would avoid the issue, and also consolidate
> (and/or help find potential bugs in) [Numbers]'s implementation.
> If that proposal is not accepted, {{RationalNumber}} should preferably be
> moved to [Imaging]'s [{{internal}}
> package|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/internal/package-summary.html].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
