Kudos Bruno, parabéns!!!

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Jul 25, 2012 at 5:51 PM, Bruno P. Kinoshita
<brunodepau...@yahoo.com.br> wrote:
> Thanks Matt, Simo!
>
> I've updated the code to use Validate.notNull and removed unreachable code. 
> Tests were created as part of FUNCTOR-12 [1]. The issue was resolved today, 
> with line coverage of 99% and branch coverage of 96% (not being crazy about 
> coverage, just tried to cover important parts of the code :-).
>
> Cheers,
>
> [1] https://issues.apache.org/jira/browse/FUNCTOR-12
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
>>________________________________
>> From: Matt Benson <gudnabr...@gmail.com>
>>To: Commons Developers List <dev@commons.apache.org>
>>Sent: Tuesday, 24 July 2012 12:46 PM
>>Subject: Re: [functor] Use Validate.notNull and remove unreachable code
>>
>>+1 to all FWIW
>>
>>Matt
>>
>>On Tue, Jul 24, 2012 at 4:28 AM, Simone Tripodi
>><simonetrip...@apache.org> wrote:
>>> Olá Bruno,
>>>
>>>> 0) I would like to add the method Validate.notNull(...) where necessary in 
>>>> [functor], if no one objects. Right now, I'm working on the following 
>>>> composite functors: TransformedProcedure, TransformedFunction, 
>>>> TransformedBinaryProcedure and TransformedBinaryFunction. None of these 
>>>> validates the arguments, while OTOH, TransposedFunction, 
>>>> TransposedPredicate and TransposedProcedure, classes in the same package, 
>>>> use Validate.notNull(...).
>>>
>>> +1
>>>
>>>> 1) There is also unreachable code, specially in equals() methods, that 
>>>> checks if an object is null before accessing its methods. But this object 
>>>> can never be null, as Validate.notNull(...) or throw NPE is used to assert 
>>>> this in the constructor. There is no other way to set this object. (You 
>>>> can still change it through reflection, but don't think it is worth 
>>>> keeping it only for this reason). I was wondering if we could remove the 
>>>> unreachable code, as there is no way to write test code for it. [2] is an 
>>>> example of unreachable code (one of its conditions), with the tests in [3] 
>>>> (there is no way to have a null predicate). It will simplify the code, 
>>>> reducing decision branches and will increase the test coverage too.
>>>
>>> sounds reasonable too, looking forward to see results!
>>>
>>> best,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to