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 20:01:05 GMT


 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


----- Original Message -----
> From: Matt Benson <gudnabrsam@gmail.com>
> To: Bruno P. Kinoshita <brunodepaulak@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
> <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
>> 
> 

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message