On Thu, May 10, 2012 at 2:09 PM, Bruno P. Kinoshita <brunodepau...@yahoo.com.br> wrote: > On 05/10/2012 03:38 PM, Matt Benson wrote: >> 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 >>> > > Hi Matt, > > Thanks for your speedy reply and for sending me the links. > > You are right indeed, there is already an issue filled for this, and my > comment is not pertinent to that issue :-) > > The comment in question refers to the item "- why are equals, hashCode and > toString defined in the Functor interface?" from [1]. Maybe we should create > a separate issue for that, WDYT?
I'm not necessarily of the opinion that this is wrong, hence my comment that a [VOTE] or [POLL] would IMHO be more appropriate than a JIRA issue at this time. Your JIRA comment mentions the example of java.util.Map, and given that I can also cite java.lang.annotation.Annotation. In light of these I would be inclined to vote in favor of letting these javadoc-hosting method declarations remain, unless someone comes along with a convincing argument. > > I will use FUNCTOR-11 to attach my patch combining the equals() methods. > > Regarding the Sanity Check Wiki entry, do you think we should add "Remove > @author tags" too? I believe it has been decided in Apache Commons to stop > using this tag (I can't remember if it is only the @author tag, or there are > other tags too). +1 here to simply open a JIRA issue, no need to discuss in the wiki. > > BTW, I filled another issue [2] today with a patch that fixes some minor > checkstyle errors in [functor]. > > Thanks again! Thank you! Matt > > -- > Bruno P. Kinoshita > http://www.kinoshita.eti.br > http://www.tupilabs.com > > [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. > [2] https://issues.apache.org/jira/browse/FUNCTOR-16 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
