commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <>
Subject Re: [collections] ReverseComparator
Date Wed, 20 Mar 2002 04:43:08 GMT
----- Original Message -----
From: "Michael A. Smith" <>
To: "Jakarta Commons Developers List" <>;
"Morgan Delagrange" <>
Cc: "Henri Yandell" <>
Sent: Tuesday, March 19, 2002 6:22 PM
Subject: Re: [collections] ReverseComparator

> On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> > If you like.  Either we add setComparator/getComparator, or we remove
> > undesirable no-op constructor.  If it were me, I'd just do the later,
> > I'm not in the "make every class a bean" camp.
> I disagree.  a no-arg constructor and dynamic instantiation of the
> comparator may be useful without a get/setComparator mechanism.  For
> example, consider an application that allows you to specify a comparator
> in a configuration file while it will use for a particular application
> specific task.  The config fail may just ask for the comparator class
> name, and the app can instantiate an instance of the comparator to use.

I don't dispute that the new no-op constructor is an improvement.  :)  But
if we're going to fix it, let's fix it right...I'm not sure we've gone far
enough yet.  Right now, the only use for that no-arg constructor is to
provide functionality identical to Collections.reverseOrder().  That doesn't
seem very useful at all.  If you want to support bean-like construction,
then let's add getter and setter methods; if not, then let's dump the no-arg
constructor entirely.  This middle ground seems inadequate.  I'd just pick
one, but I don't want to tick anybody off.

Here's my case for just removing the no-arg comparator.  1) Bean-like
construction of a Comparator seems unimportant as a feature.  2) If only the
constructor can set the comparator that's reversed, it's not possible to do
something naughty like changing a comparator after it has already been
assigned to a SortedXXX.

If folks really want no-arg, then let's at least add a setter method.  For
me, that option is a distant second, but livable.

> get/setComparator methods are really only useful for altering the
> underlying comparator once the reverse/inverse comparator has been
> constructed.  I think this is bad because the underlying comparator is
> part of the functionality, and providing modification of it thus changes
> the functionality of the reverse/inverse comparator.  That doesn't seem
> like an appropriate attribute modification.

Definitely agree.  I'd prefer to not have getter/setter methods.

> Since there's been a bit of discussion on the issue, and I haven't really
> heard any objections to my diff (fixing the comparator with respect to the
> comparator contract), I'm going to check that in. I'm also going to check
> in the argument swap rather than multiplication.  We can continue
> discussion on the rename and whether or not to have a no-arg constructor.

-0 for a no-arg constructor.

-1 for the name change, only because it has the same connotation as and
shares terminology with Collections.reverseOrder().  Might as well be
consistent.  If the term seems awkward, then a more specific definition in
the Javadoc should suffice.

> regards,
> michael

Do You Yahoo!?
Get your free address at

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message