Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com
----- Original Message ----- > From: Matt Benson <gudnabr...@gmail.com> > To: Bruno P. Kinoshita <brunodepau...@yahoo.com.br> > Cc: Commons Developers List <dev@commons.apache.org> > Sent: Thursday, 10 May 2012 4:44 PM > Subject: Re: [functor] Remove duplicated equals() methods > > 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 >> > Hi Matt, > +1 here to simply open a JIRA issue, no need to discuss in the wiki. Thanks, I will open a JIRA issue to remove @author tags. > 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. +1. I've only added my findings in that comment, but I really have no strong opinion on this issue. I thought about an issue so that comments and suggestions could be added there, but a vote would be better indeed :-) Many thanks! Bruno --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
