[ 
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17743803#comment-17743803
 ] 

Gary Lucas edited comment on IMAGING-358 at 7/17/23 1:17 PM:
-------------------------------------------------------------

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 
rules.  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 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.

 

 


was (Author: gwlucas):
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 
rules.  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)

Reply via email to