Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 64491 invoked from network); 27 Sep 2002 04:26:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Sep 2002 04:26:12 -0000 Received: (qmail 13384 invoked by uid 97); 27 Sep 2002 04:27:01 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 13343 invoked by uid 97); 27 Sep 2002 04:27:00 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 13320 invoked by uid 98); 27 Sep 2002 04:26:59 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Type: text/plain; charset="iso-8859-1" From: Steve Downey To: "Jakarta Commons Developers List" Subject: Re: [beanutils] Question about BeanComparator Date: Fri, 27 Sep 2002 00:23:09 -0400 User-Agent: KMail/1.4.1 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209270023.10585.steve.downey@netfolio.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. =20 > > >However, I was also thinking that I would > >create SafeComparator that would be smart enough to make nulls into bl= ank > >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=3D=3Dnothing\" for or= dering > purposes (as opposed to identity purposes). > No, that's probably a bad idea. Saying "" =3D=3D null is likely to get yo= u into=20 trouble.=20 You can't separate ordering from equals. compare =3D=3D 0 is, by definiti= on, an=20 equality class. It might not be the same as equals(), but if it isn't you= do=20 need to be very careful. > But adding +1 to false doesn\'t make it true (except in some dialects o= f > assembler that is). > > And how would you compare null with fx. Integer? As in: > > bean a: > Integer i =3D null; > > bean b: > Integer i =3D 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 i= t.=20 Null would have to be either greater or less than all other values, inclu= ding=20 Inf and NaN. Or define what ever you want, as long as it's outside of MAX= and=20 MIN. Take a look at [lang]'s CompareToBuilder, which has some reverse=20 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 i= s 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=20 do have to guarantee is the three requirements for comparison: sgn(x.compareTo(y)) =3D=3D -sgn(y.compareTo(x)) (x.compareTo(y)>0 && y.compareTo(z)>0) implies x.compareTo(z)>0 x.compareTo(y)=3D=3D0 implies that sgn(x.compareTo(z)) =3D=3D sgn(y.comp= areTo(z)),=20 for all z One important implication is that you can not meaningfully compare a subc= lass=20 to a superclass. It will eventually cause a problem. -- To unsubscribe, e-mail: For additional commands, e-mail: