commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br>
Subject Re: [functor] Remove duplicated equals() methods
Date Thu, 10 May 2012 19:09:00 GMT
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 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).

BTW, I filled another issue [2] today with a patch that fixes some minor checkstyle errors
in [functor].

Thanks again!

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