commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [functor] Remove duplicated equals() methods
Date Thu, 10 May 2012 19:44:08 GMT
On Thu, May 10, 2012 at 2:09 PM, Bruno P. Kinoshita
<> wrote:
> On 05/10/2012 03:38 PM, Matt Benson wrote:
>> On Thu, May 10, 2012 at 1:27 PM, Bruno P. Kinoshita
>> <>  wrote:
>>> Hi all,
>>> While I am still trying to find time to work on a proposal for enhancements in
the generators API in [functor] (, 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 (
>>> 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 (
>> 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]
>> [2]
>>> Thanks in advance!
>>> Bruno P. Kinoshita
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> 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

> 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!


> --
> Bruno P. Kinoshita
> [1]
> [2]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message