[
https://issues.apache.org/jira/browse/IMAGING-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17743563#comment-17743563
]
Gary Lucas edited comment on IMAGING-358 at 7/16/23 8:11 PM:
-------------------------------------------------------------
Well, there always a trade off with this kind of thing. In general, I really
dislike the idea of adding new dependencies to Commons Imaging (or any other
software package). As a software developer, it makes my life more complicated
when the library I want to use requires that I also include others I don't
need. However, if there is a module that is truly common, then it doesn't make
sense to implement it different ways. Adding unnecessary libraries adds bloat.
But implementing redundant classes also adds bloat. Is there a Nash balance
somewhere in this game? Finding it might be a challenge.
In the case of Imaging-309, it turned out that the rational number format used
by TIFF just wasn't a perfect fit with that used in the math library. Some of
the rules were a little different. And since the rules were defined as part of
the TIFF format specification, it wasn't like we could change them. And
modifying the math libary's NumberFormat class struck me as a bit risky because
we would be saddling a generic implementation with some ad hoc requirements to
support a single edge case (the TIFF format).
Finally, I'm not sure about the scoping. As I recall, RationalNumber was used
in multiple packages. I will look at the code later.
was (Author: gwlucas):
Well, there always a trade off with this kind of thing. In general, I really
dislike the idea of adding new dependencies to Commons Imaging (or any other
software package). As a software developer, it makes my life more complicated
when the library I want to use requires that I also include others I don't
need. However, if there is a module that is truly common, then it doesn't make
sense to implement it different ways. Adding unnecessary libraries adds bloat.
But implementing redundant classes also adds bloat. Is there a Nash balance
somewhere in this game? Finding it might be a challenge.
In the case of Imaging-309, it turned out that the rational number format used
by TIFF just wasn't a perfect fit with that used in the math library. Some of
the rules were a little different. And since the rules were defined as part of
the TIFF format specification, it wasn't like we could change them. I'm not
sure about the scoping. As I recall, RationalNumber was used in multiple
packages. I will look at the code later.
> "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)
