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
