commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [beanutils] Question about BeanComparator
Date Fri, 27 Sep 2002 04:23:09 GMT
On Thursday 26 September 2002 05:59 pm, Ola Berg wrote:
> Eric Pugh writes:
> >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...?
>
> I see \"safing\" these values as very problematic.
>
> Letting null having the same ordering impact as \"\" could be regarded as
> intuitive, both indicating something like \"value==nothing\" for ordering
> purposes (as opposed to identity purposes).
>
No, that's probably a bad idea. Saying "" == null is likely to get you into 
trouble. 

You can't separate ordering from equals. compare == 0 is, by definition, an 
equality class. It might not be the same as equals(), but if it isn't you do 
need to be very careful.

> But adding +1 to false doesn\'t make it true (except in some dialects of
> assembler that is).
>
> And how would you compare null with fx. Integer? As in:
>
> bean a:
>     Integer i = null;
>
> bean b:
>     Integer i = new Integer(0);
>
>
> Or how no you compare null with negative infinity?
>
Same way you compare a value with neg or pos infinity. You special case it. 
Null would have to be either greater or less than all other values, including 
Inf and NaN. Or define what ever you want, as long as it's outside of MAX and 
MIN. Take a look at [lang]'s CompareToBuilder, which has some reverse 
engineered code to deal with a total ordering of doubles and floats.

It does not handle null, though.

> Can _any_ strategy in the SafeComparator be regarded _right_ here (ie is it
> possible to \"safe\" the troublesome values in a meaningful way)?
>
> /O
It's possible, the question is will it get you into trouble or not.  What you 
do have to guarantee is the three requirements for comparison:

sgn(x.compareTo(y)) == -sgn(y.compareTo(x))
(x.compareTo(y)>0 && y.compareTo(z)>0) implies x.compareTo(z)>0
x.compareTo(y)==0  implies that sgn(x.compareTo(z)) == sgn(y.compareTo(z)), 
for all z

One important implication is that you can not meaningfully compare a subclass 
to a superclass. It will eventually cause a problem.



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message