On Thu, May 10, 2012 at 1:27 PM, Bruno P. Kinoshita <brunodepau...@yahoo.com.br> wrote: > Hi all, > > While I am still trying to find time to work on a proposal for enhancements > in the generators API in [functor] > (https://issues.apache.org/jira/browse/FUNCTOR-14), I'm reviewing other > pending issues, including the one regarding test coverage. > > The comparators API seemed to be lacking tests for some decision branches. > But looking closely at the code, I realized that there were two equals code > in some comparator functors. Then I set up a Sonar instance to scan the code, > and found that it is common in many other parts of the code > (http://66.228.56.222/sonar/drilldown/violations/org.apache.commons:commons-functor?severity=CRITICAL). > > Does anybody know if there is some reason for having both equals(Object that) > and equals(SomeFunctor<?> that)? I think we could merge both methods in only > one. The Generators in [functor] have only one equals() method, and compares > against this, uses instanceof, etc. I had a quick look on [math3] and > [lang3], and looks like they both use only one equals() method, compares > against this, uses instaceof, etc. > > If there is no objection here, I could create a patch for this in Jira, > merging both equals() methods in one :-) Then after this I will proceed > writing tests to increase the test coverage > (https://issues.apache.org/jira/browse/FUNCTOR-12). >
Bruno, As far as I know this pattern was introduced by one of [functor]'s original authors and must simply have been his preference. Personally I agree that this is not what your average Java developer probably expects to see in your average Java codebase, and would support combining these methods. This is documented at [1] and filed at [2] (where your earlier comment is valid, and is also mentioned at [1], but doesn't IMHO pertain specifically to this JIRA issue). Regards, Matt [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-11 > Thanks in advance! > > Bruno P. Kinoshita > http://kinoshita.eti.br > http://tupilabs.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
