I think Ola and Robert and Henri are all correct.. I think I was just looking for a bit of a push in the right direction! Should I submit my test case for BeanComparator now (with my test on booleans removed), or wait a bit?
Also, I will pull out my code (in my environment I pretty much know if true comes before false etc) and put them into some sort of SafeComparator in my own tree. Where is ObjectComparator in terms of work? Should I use it, or just go with my own somewhat nasty SafeComparator filled with hardcoded assumptions? Eric -----Original Message----- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 6:03 PM To: Jakarta Commons Developers List Subject: Re: [beanutils] Question about BeanComparator I concur with both Ola and Robert. The Boolean aspect is just a single part of what I've been calling ObjectComparator, a Comparator than can compare anything. It has big issues in terms of having to delegate to various hard coded comparators, and be pluggable with user's comparators. There's nothing to stop you doing: BeanComparator cmp = new BeanComparator("active", new BooleanComparator()); is there? Hen On Thu, 26 Sep 2002, robert burrell donkin wrote: > hi eric > > 1. i do think that an intelligent bean comparator would be cool and > plug-ins seem like the right way to do it. > 2. just FYI we're pushing towards a beanutils release very soon now so be > careful about committing any signatures that might need to be changed > later. > > - robert > > On Thursday, September 26, 2002, at 10:24 PM, [EMAIL PROTECTED] wrote: > > > Hi, > > > > This question is mostly focused for Henri, but anyone can comment. I am > > working on a testcase for BeanComparator, and one that comes up is if I > > try > > and compare two Boolean objects. Because Boolean doesn't support > > Comparable, they crash. I change BeanComparator to have a makeComparable > > method: > > > > private Comparable makeComparable( Object o ) > > throws ClassCastException { > > Comparable value = null; > > if ( o == null ) { > > value = new String( "" ); > > } > > else if ( o instanceof Boolean ) { > > Boolean b = (Boolean) o; > > if ( b.booleanValue() ) { > > value = new Integer( "1" ); > > } > > else { > > value = new Integer( "0" ); > > } > > } > > else if ( o instanceof Comparable ) { > > value = (Comparable) o; > > } > > else { > > throw new ClassCastException( "Object " + o.getClass().getName() > > + " > > is not a comparable datatype, or convertable." ); > > } > > return value; > > } > > > > Now, I know that this means that as various datatypes are introduced, then > > this needs to be changed. What I am wondering though is that being able > > to > > compare booleans is pretty basic. However, I was also thinking that I > > would > > create SafeComparator that would be smart enough to make nulls into blank > > strings, booleans into 1 and 0 etc...? Heck, if you got crazy, it could > > be > > pluggable similar to the transformer stuff so that any datatype could be > > made a comparable object. What are your opinions? I at least want to get > > my first cut of unit tests into CVS. > > > > Eric Pugh > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]. > > org> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]. > > org> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
