commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
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
<brunodepaulak@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
>> <brunodepaulak@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message