You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Michael A. Smith" <ma...@apache.org> on 2002/03/19 03:50:00 UTC
[collections] PriorityQueue
In order to update BinaryHeap to take generic Objects rather than
requiring Comparable objects, I will need to make an equivalent update to
PriortyQueue. Any objections?
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Henri Yandell <ba...@generationjava.com>.
Am hitting myself for missing this email. Sorry. Why's there not big red
abort button.
Hen
On Tue, 19 Mar 2002, Michael A. Smith wrote:
> I just answered my own question. Collections.reverseOrder()
> inverts/reverses the natural ordering, but does not invert/reverse the
> ordering of an arbitrary comparator like the collections version does.
> That's a good reason to keep the commons version around.
>
> michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by "Michael A. Smith" <ma...@apache.org>.
On Tue, 19 Mar 2002, Michael A. Smith wrote:
> I'm not going to argue this anymore though. I've changed my position --
> why is this class even included in commons when the JDK provides a
> reverse/inverse comparator already? @see Collections.reverseOrder()
I just answered my own question. Collections.reverseOrder()
inverts/reverses the natural ordering, but does not invert/reverse the
ordering of an arbitrary comparator like the collections version does.
That's a good reason to keep the commons version around.
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Morgan Delagrange <md...@yahoo.com>.
OK, I give up. I don't see the benefit of this constructor without a setter
method, besides providing easier Digester configuration. :P But I don't
want to go on about it; if you're dead-set against setter methods or
removing the constructor entirely, there's nothing I can do about it.
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by "Michael A. Smith" <ma...@apache.org>.
On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> > 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.
Having the no-arg be equivalent to Collections.reverseOrder is still
useful -- there's no easy way to specify the comparator returned from
Collections.reverseOrder() as a configuration option in, say, an digestor
based configuration file:
<field name="name"
comparator="org.apache.commons.collections.comparators.ComparableComparator"
>
<field name="date"
comparator="org.apache.commons.collections.comparators.ReverseComparator"
>
That's the big advantage that makes me want to keep the no-arg even though
equivalant functionality exists in Collections.reverseOrder.
> 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.
1) its important for the use-case above.
2) having a no-arg doesn't imply the comparator can be changed after
assigned to a SortedXXX.
It seems like both of these arguments *do* apply against adding a
setComparator method though: it seems unimportant as a feature to be able
to change the underlying comparator (rather than just creating a new one),
and changing the functionality of the comparator after its assigned to a
SortedXXX is a Bad Thing.
I should also mention that a no-arg constructor does not imply that the
comparator is a "bean" and needs to have get/set methods for all its
attributes. And even if it does, I would still argue that the comparator
is would not be a read/write attribute. I'd be ok with a get method if
that makes things more "bean-like".
> 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.
I will -1 adding a setComparator method. I think its too dangerous to
allow the comparator to change behavior after it has been constructed.
> > 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.
ok, so we agree. :)
> > 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.
This is weird actually. That no-arg has been in there since the class was
added in February, and probably before that while the class existed in the
util sandbox. Status-quo in this case is to leave the no-arg constructor.
My changes were merely to "fix" the no-arg so that it conforms to the
Comparator contract. Makes for some interesting apache style voting. :)
> -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.
Fine by me. After removing the multiplicationg in favor of just reversing
the elements, it now seems just as appropriate to calling it a
ReverseComparator as it does to call it an InverseComparator. ;)
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Michael A. Smith" <ma...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
"Morgan Delagrange" <mo...@apache.org>
Cc: "Henri Yandell" <ba...@generationjava.com>
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
the
> > undesirable no-op constructor. If it were me, I'd just do the later,
but
> > 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 @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by "Michael A. Smith" <ma...@apache.org>.
On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> If you like. Either we add setComparator/getComparator, or we remove the
> undesirable no-op constructor. If it were me, I'd just do the later, but
> 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.
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.
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.
regards,
michael
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> "Morgan Delagrange" <mo...@apache.org>
> Sent: Tuesday, March 19, 2002 2:08 PM
> Subject: Re: [collections] ReverseComparator
>
>
> > The only reason I'd normally expect to have an empty constructor would be
> > for reflection. To that end, should it have a setComparator/getComparator
> > methods?
> >
> > Hen
> >
> > On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> >
> > > Do we need an empty constructor? If it does not produce desirable
> > > behaviour, why not can it?
> > >
> > > ----- Original Message -----
> > > From: "Henri Yandell" <ba...@generationjava.com>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > Sent: Tuesday, March 19, 2002 11:11 AM
> > > Subject: Re: [collections] ReverseComparator
> > >
> > >
> > > >
> > > > Functionality wise, I feel that Michael's proposed change is a
> negative
> > > > move. However he is absolutely right in all of his points. The
> current -1
> > > > does break the Comparator contract, the -1* is unnecessary coding,
> making
> > > > the constructor take ComparableComparator is then no different from
> > > > reverseOrder, and the name then does make more sense as
> InverseComparator.
> > > >
> > > > It's like a stack of dominoes :) Each point seems not necessarily true
> > > > until you realise each one leads to the next. So I'm:
> > > >
> > > > +1 on removing the -1*.
> > > > +1 on killing the current empty constructor.
> > > > +0 on using ComparableComparator which simulates reverseOrder
> > > functionality.
> > > > It feels bad to replicate this, but we need an empty constructor.
> > > > +0 on the name of the class. It does behave more as an
> InverseComparator
> > > > from a mathematical point of view (which I share), but Reverse does
> > > > seem more readable.
> > > >
> > > > Hen
> > > >
> > > >
> > > > On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> > > >
> > > > > Michael suggested that the no-op constructor essentially behave like
> > > this:
> > > > >
> > > > > ReverseComparator() {
> > > > > this(ComparableComparator.getInstance());
> > > > > }
> > > > >
> > > > > What do you think, Hen? Do you think that is preferable, or do you
> > > prefer
> > > > > your initial behaviour (reversing the List).
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Henri Yandell" <ba...@generationjava.com>
> > > > > To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> > > > > Sent: Tuesday, March 19, 2002 7:50 AM
> > > > > Subject: Re: [collections] ReverseComparator
> > > > >
> > > > >
> > > > > >
> > > > > > I'm happy with the name Inverse as it is more what the comparator
> > > does.
> > > > > > Reverse makes it easier to see how it can be used for one case,
> but
> > > will
> > > > > > hide other meanings.
> > > > > >
> > > > > > Why does this exist over Collections.reverseOrder? Because the Sun
> > > version
> > > > > > is limited. Why can I only reverse Comparables? Really there
> should be
> > > a
> > > > > > Collections.reverseOrder(Comparator) as well.
> > > > > >
> > > > > > Hen
> > > > > >
> > > > > > > I agree that reverse is common terminology when sorting, but I
> > > disagree
> > > > > > > that sorting is intrinsicly what a comparator does. While
> sorting is
> > > > > > > probably the most common use-case for comparators, the
> comparator
> > > itself
> > > > > > > does not do any sorting. It compares objects and returns a
> > > negative,
> > > > > zero
> > > > > > > value, or positive result. It doesn't rearrange, reverse,
> order, or
> > > > > > > "sort". It just compares two objects. This particular
> comparator
> > > > > > > "inverses" the result of the compare to be a positive, zero
> value,
> > > or
> > > > > > > negative result (respectively). I use "inverse" here in its
> > > > > mathematical
> > > > > > > sense of inverting the result, since that's all this comparator
> is
> > > > > doing.
> > > > > > >
> > > > > > > I'm not going to argue this anymore though. I've changed my
> > > position --
> > > > > > > why is this class even included in commons when the JDK provides
> a
> > > > > > > reverse/inverse comparator already? @see
> Collections.reverseOrder()
> > > > > > >
> > > > > > > regards,
> > > > > > > michael
> > > > > > >
> > > > > > > > "Michael A. Smith" wrote:
> > > > > > > > >[snip]
> > > > > > > > > Additionally, I think that "InverseComparator" is a more
> > > appropriate
> > > > > name,
> > > > > > > > > as "inverse" has a more direct meaning (to me at least).
> > > Inverse
> > > > > has the
> > > > > > > > > mathematical meaning of the opposite sign which is exactly
> what
> > > this
> > > > > > > > > comparator does. Reverse, on the other hand, implies
> switching
> > > the
> > > > > order
> > > > > > > > > of something, the comparator isn't really switching the
> order
> > > > > (although a
> > > > > > > > > collection using the comparator may be "reversed" if it uses
> the
> > > > > "inverse"
> > > > > > > > > comparator).
> > > > > > > > >
> > > > > > > > > Thoughts?
> > > > > > > > >[snip]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > > > _________________________________________________________
> > > > > Do You Yahoo!?
> > > > > Get your free @yahoo.com address at http://mail.yahoo.com
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Morgan Delagrange <md...@yahoo.com>.
If you like. Either we add setComparator/getComparator, or we remove the
undesirable no-op constructor. If it were me, I'd just do the later, but
I'm not in the "make every class a bean" camp.
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
"Morgan Delagrange" <mo...@apache.org>
Sent: Tuesday, March 19, 2002 2:08 PM
Subject: Re: [collections] ReverseComparator
> The only reason I'd normally expect to have an empty constructor would be
> for reflection. To that end, should it have a setComparator/getComparator
> methods?
>
> Hen
>
> On Tue, 19 Mar 2002, Morgan Delagrange wrote:
>
> > Do we need an empty constructor? If it does not produce desirable
> > behaviour, why not can it?
> >
> > ----- Original Message -----
> > From: "Henri Yandell" <ba...@generationjava.com>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Tuesday, March 19, 2002 11:11 AM
> > Subject: Re: [collections] ReverseComparator
> >
> >
> > >
> > > Functionality wise, I feel that Michael's proposed change is a
negative
> > > move. However he is absolutely right in all of his points. The
current -1
> > > does break the Comparator contract, the -1* is unnecessary coding,
making
> > > the constructor take ComparableComparator is then no different from
> > > reverseOrder, and the name then does make more sense as
InverseComparator.
> > >
> > > It's like a stack of dominoes :) Each point seems not necessarily true
> > > until you realise each one leads to the next. So I'm:
> > >
> > > +1 on removing the -1*.
> > > +1 on killing the current empty constructor.
> > > +0 on using ComparableComparator which simulates reverseOrder
> > functionality.
> > > It feels bad to replicate this, but we need an empty constructor.
> > > +0 on the name of the class. It does behave more as an
InverseComparator
> > > from a mathematical point of view (which I share), but Reverse does
> > > seem more readable.
> > >
> > > Hen
> > >
> > >
> > > On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> > >
> > > > Michael suggested that the no-op constructor essentially behave like
> > this:
> > > >
> > > > ReverseComparator() {
> > > > this(ComparableComparator.getInstance());
> > > > }
> > > >
> > > > What do you think, Hen? Do you think that is preferable, or do you
> > prefer
> > > > your initial behaviour (reversing the List).
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Henri Yandell" <ba...@generationjava.com>
> > > > To: "Jakarta Commons Developers List"
<co...@jakarta.apache.org>
> > > > Sent: Tuesday, March 19, 2002 7:50 AM
> > > > Subject: Re: [collections] ReverseComparator
> > > >
> > > >
> > > > >
> > > > > I'm happy with the name Inverse as it is more what the comparator
> > does.
> > > > > Reverse makes it easier to see how it can be used for one case,
but
> > will
> > > > > hide other meanings.
> > > > >
> > > > > Why does this exist over Collections.reverseOrder? Because the Sun
> > version
> > > > > is limited. Why can I only reverse Comparables? Really there
should be
> > a
> > > > > Collections.reverseOrder(Comparator) as well.
> > > > >
> > > > > Hen
> > > > >
> > > > > > I agree that reverse is common terminology when sorting, but I
> > disagree
> > > > > > that sorting is intrinsicly what a comparator does. While
sorting is
> > > > > > probably the most common use-case for comparators, the
comparator
> > itself
> > > > > > does not do any sorting. It compares objects and returns a
> > negative,
> > > > zero
> > > > > > value, or positive result. It doesn't rearrange, reverse,
order, or
> > > > > > "sort". It just compares two objects. This particular
comparator
> > > > > > "inverses" the result of the compare to be a positive, zero
value,
> > or
> > > > > > negative result (respectively). I use "inverse" here in its
> > > > mathematical
> > > > > > sense of inverting the result, since that's all this comparator
is
> > > > doing.
> > > > > >
> > > > > > I'm not going to argue this anymore though. I've changed my
> > position --
> > > > > > why is this class even included in commons when the JDK provides
a
> > > > > > reverse/inverse comparator already? @see
Collections.reverseOrder()
> > > > > >
> > > > > > regards,
> > > > > > michael
> > > > > >
> > > > > > > "Michael A. Smith" wrote:
> > > > > > > >[snip]
> > > > > > > > Additionally, I think that "InverseComparator" is a more
> > appropriate
> > > > name,
> > > > > > > > as "inverse" has a more direct meaning (to me at least).
> > Inverse
> > > > has the
> > > > > > > > mathematical meaning of the opposite sign which is exactly
what
> > this
> > > > > > > > comparator does. Reverse, on the other hand, implies
switching
> > the
> > > > order
> > > > > > > > of something, the comparator isn't really switching the
order
> > > > (although a
> > > > > > > > collection using the comparator may be "reversed" if it uses
the
> > > > "inverse"
> > > > > > > > comparator).
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >[snip]
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > > > _________________________________________________________
> > > > Do You Yahoo!?
> > > > Get your free @yahoo.com address at http://mail.yahoo.com
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Henri Yandell <ba...@generationjava.com>.
The only reason I'd normally expect to have an empty constructor would be
for reflection. To that end, should it have a setComparator/getComparator
methods?
Hen
On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> Do we need an empty constructor? If it does not produce desirable
> behaviour, why not can it?
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Tuesday, March 19, 2002 11:11 AM
> Subject: Re: [collections] ReverseComparator
>
>
> >
> > Functionality wise, I feel that Michael's proposed change is a negative
> > move. However he is absolutely right in all of his points. The current -1
> > does break the Comparator contract, the -1* is unnecessary coding, making
> > the constructor take ComparableComparator is then no different from
> > reverseOrder, and the name then does make more sense as InverseComparator.
> >
> > It's like a stack of dominoes :) Each point seems not necessarily true
> > until you realise each one leads to the next. So I'm:
> >
> > +1 on removing the -1*.
> > +1 on killing the current empty constructor.
> > +0 on using ComparableComparator which simulates reverseOrder
> functionality.
> > It feels bad to replicate this, but we need an empty constructor.
> > +0 on the name of the class. It does behave more as an InverseComparator
> > from a mathematical point of view (which I share), but Reverse does
> > seem more readable.
> >
> > Hen
> >
> >
> > On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> >
> > > Michael suggested that the no-op constructor essentially behave like
> this:
> > >
> > > ReverseComparator() {
> > > this(ComparableComparator.getInstance());
> > > }
> > >
> > > What do you think, Hen? Do you think that is preferable, or do you
> prefer
> > > your initial behaviour (reversing the List).
> > >
> > >
> > > ----- Original Message -----
> > > From: "Henri Yandell" <ba...@generationjava.com>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > Sent: Tuesday, March 19, 2002 7:50 AM
> > > Subject: Re: [collections] ReverseComparator
> > >
> > >
> > > >
> > > > I'm happy with the name Inverse as it is more what the comparator
> does.
> > > > Reverse makes it easier to see how it can be used for one case, but
> will
> > > > hide other meanings.
> > > >
> > > > Why does this exist over Collections.reverseOrder? Because the Sun
> version
> > > > is limited. Why can I only reverse Comparables? Really there should be
> a
> > > > Collections.reverseOrder(Comparator) as well.
> > > >
> > > > Hen
> > > >
> > > > > I agree that reverse is common terminology when sorting, but I
> disagree
> > > > > that sorting is intrinsicly what a comparator does. While sorting is
> > > > > probably the most common use-case for comparators, the comparator
> itself
> > > > > does not do any sorting. It compares objects and returns a
> negative,
> > > zero
> > > > > value, or positive result. It doesn't rearrange, reverse, order, or
> > > > > "sort". It just compares two objects. This particular comparator
> > > > > "inverses" the result of the compare to be a positive, zero value,
> or
> > > > > negative result (respectively). I use "inverse" here in its
> > > mathematical
> > > > > sense of inverting the result, since that's all this comparator is
> > > doing.
> > > > >
> > > > > I'm not going to argue this anymore though. I've changed my
> position --
> > > > > why is this class even included in commons when the JDK provides a
> > > > > reverse/inverse comparator already? @see Collections.reverseOrder()
> > > > >
> > > > > regards,
> > > > > michael
> > > > >
> > > > > > "Michael A. Smith" wrote:
> > > > > > >[snip]
> > > > > > > Additionally, I think that "InverseComparator" is a more
> appropriate
> > > name,
> > > > > > > as "inverse" has a more direct meaning (to me at least).
> Inverse
> > > has the
> > > > > > > mathematical meaning of the opposite sign which is exactly what
> this
> > > > > > > comparator does. Reverse, on the other hand, implies switching
> the
> > > order
> > > > > > > of something, the comparator isn't really switching the order
> > > (although a
> > > > > > > collection using the comparator may be "reversed" if it uses the
> > > "inverse"
> > > > > > > comparator).
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >[snip]
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Morgan Delagrange <md...@yahoo.com>.
Do we need an empty constructor? If it does not produce desirable
behaviour, why not can it?
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, March 19, 2002 11:11 AM
Subject: Re: [collections] ReverseComparator
>
> Functionality wise, I feel that Michael's proposed change is a negative
> move. However he is absolutely right in all of his points. The current -1
> does break the Comparator contract, the -1* is unnecessary coding, making
> the constructor take ComparableComparator is then no different from
> reverseOrder, and the name then does make more sense as InverseComparator.
>
> It's like a stack of dominoes :) Each point seems not necessarily true
> until you realise each one leads to the next. So I'm:
>
> +1 on removing the -1*.
> +1 on killing the current empty constructor.
> +0 on using ComparableComparator which simulates reverseOrder
functionality.
> It feels bad to replicate this, but we need an empty constructor.
> +0 on the name of the class. It does behave more as an InverseComparator
> from a mathematical point of view (which I share), but Reverse does
> seem more readable.
>
> Hen
>
>
> On Tue, 19 Mar 2002, Morgan Delagrange wrote:
>
> > Michael suggested that the no-op constructor essentially behave like
this:
> >
> > ReverseComparator() {
> > this(ComparableComparator.getInstance());
> > }
> >
> > What do you think, Hen? Do you think that is preferable, or do you
prefer
> > your initial behaviour (reversing the List).
> >
> >
> > ----- Original Message -----
> > From: "Henri Yandell" <ba...@generationjava.com>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Tuesday, March 19, 2002 7:50 AM
> > Subject: Re: [collections] ReverseComparator
> >
> >
> > >
> > > I'm happy with the name Inverse as it is more what the comparator
does.
> > > Reverse makes it easier to see how it can be used for one case, but
will
> > > hide other meanings.
> > >
> > > Why does this exist over Collections.reverseOrder? Because the Sun
version
> > > is limited. Why can I only reverse Comparables? Really there should be
a
> > > Collections.reverseOrder(Comparator) as well.
> > >
> > > Hen
> > >
> > > > I agree that reverse is common terminology when sorting, but I
disagree
> > > > that sorting is intrinsicly what a comparator does. While sorting is
> > > > probably the most common use-case for comparators, the comparator
itself
> > > > does not do any sorting. It compares objects and returns a
negative,
> > zero
> > > > value, or positive result. It doesn't rearrange, reverse, order, or
> > > > "sort". It just compares two objects. This particular comparator
> > > > "inverses" the result of the compare to be a positive, zero value,
or
> > > > negative result (respectively). I use "inverse" here in its
> > mathematical
> > > > sense of inverting the result, since that's all this comparator is
> > doing.
> > > >
> > > > I'm not going to argue this anymore though. I've changed my
position --
> > > > why is this class even included in commons when the JDK provides a
> > > > reverse/inverse comparator already? @see Collections.reverseOrder()
> > > >
> > > > regards,
> > > > michael
> > > >
> > > > > "Michael A. Smith" wrote:
> > > > > >[snip]
> > > > > > Additionally, I think that "InverseComparator" is a more
appropriate
> > name,
> > > > > > as "inverse" has a more direct meaning (to me at least).
Inverse
> > has the
> > > > > > mathematical meaning of the opposite sign which is exactly what
this
> > > > > > comparator does. Reverse, on the other hand, implies switching
the
> > order
> > > > > > of something, the comparator isn't really switching the order
> > (although a
> > > > > > collection using the comparator may be "reversed" if it uses the
> > "inverse"
> > > > > > comparator).
> > > > > >
> > > > > > Thoughts?
> > > > > >[snip]
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Henri Yandell <ba...@generationjava.com>.
Functionality wise, I feel that Michael's proposed change is a negative
move. However he is absolutely right in all of his points. The current -1
does break the Comparator contract, the -1* is unnecessary coding, making
the constructor take ComparableComparator is then no different from
reverseOrder, and the name then does make more sense as InverseComparator.
It's like a stack of dominoes :) Each point seems not necessarily true
until you realise each one leads to the next. So I'm:
+1 on removing the -1*.
+1 on killing the current empty constructor.
+0 on using ComparableComparator which simulates reverseOrder functionality.
It feels bad to replicate this, but we need an empty constructor.
+0 on the name of the class. It does behave more as an InverseComparator
from a mathematical point of view (which I share), but Reverse does
seem more readable.
Hen
On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> Michael suggested that the no-op constructor essentially behave like this:
>
> ReverseComparator() {
> this(ComparableComparator.getInstance());
> }
>
> What do you think, Hen? Do you think that is preferable, or do you prefer
> your initial behaviour (reversing the List).
>
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Tuesday, March 19, 2002 7:50 AM
> Subject: Re: [collections] ReverseComparator
>
>
> >
> > I'm happy with the name Inverse as it is more what the comparator does.
> > Reverse makes it easier to see how it can be used for one case, but will
> > hide other meanings.
> >
> > Why does this exist over Collections.reverseOrder? Because the Sun version
> > is limited. Why can I only reverse Comparables? Really there should be a
> > Collections.reverseOrder(Comparator) as well.
> >
> > Hen
> >
> > > I agree that reverse is common terminology when sorting, but I disagree
> > > that sorting is intrinsicly what a comparator does. While sorting is
> > > probably the most common use-case for comparators, the comparator itself
> > > does not do any sorting. It compares objects and returns a negative,
> zero
> > > value, or positive result. It doesn't rearrange, reverse, order, or
> > > "sort". It just compares two objects. This particular comparator
> > > "inverses" the result of the compare to be a positive, zero value, or
> > > negative result (respectively). I use "inverse" here in its
> mathematical
> > > sense of inverting the result, since that's all this comparator is
> doing.
> > >
> > > I'm not going to argue this anymore though. I've changed my position --
> > > why is this class even included in commons when the JDK provides a
> > > reverse/inverse comparator already? @see Collections.reverseOrder()
> > >
> > > regards,
> > > michael
> > >
> > > > "Michael A. Smith" wrote:
> > > > >[snip]
> > > > > Additionally, I think that "InverseComparator" is a more appropriate
> name,
> > > > > as "inverse" has a more direct meaning (to me at least). Inverse
> has the
> > > > > mathematical meaning of the opposite sign which is exactly what this
> > > > > comparator does. Reverse, on the other hand, implies switching the
> order
> > > > > of something, the comparator isn't really switching the order
> (although a
> > > > > collection using the comparator may be "reversed" if it uses the
> "inverse"
> > > > > comparator).
> > > > >
> > > > > Thoughts?
> > > > >[snip]
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by "Michael A. Smith" <ma...@apache.org>.
On Tue, 19 Mar 2002, Morgan Delagrange wrote:
> Michael suggested that the no-op constructor essentially behave like this:
>
> ReverseComparator() {
> this(ComparableComparator.getInstance());
> }
>
> What do you think, Hen? Do you think that is preferable, or do you prefer
> your initial behaviour (reversing the List).
my point was that the initial behavior doesn't necessarily "reverse" a
list. Always returning -1 from the compare function may have some pretty
strange consequences and dependes heavily on the implementation of the
List to determine whether it would actually "reverse" anything. Using the
comparable comparator as a base comparator which is then reversed in the
compare I think has the "proper" behavior of reversing the comparisons
(and thus more correctly reversing a list).
I could probably throw together an example this evening showing how broken
the no-arg constructor is, but I think anyone could do the same fairly
quickly. Use the no-arg constructor as the comparator to a "TreeSet" and
add a bunch of strings in random order. Iterate the elements in the tree
set, and I'm willing to bet that the elements are going to be in some sort
of order based on the order they were inserted, instead of the order or
inverse order of the elements themselves.
regards,
michael
>
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Tuesday, March 19, 2002 7:50 AM
> Subject: Re: [collections] ReverseComparator
>
>
> >
> > I'm happy with the name Inverse as it is more what the comparator does.
> > Reverse makes it easier to see how it can be used for one case, but will
> > hide other meanings.
> >
> > Why does this exist over Collections.reverseOrder? Because the Sun version
> > is limited. Why can I only reverse Comparables? Really there should be a
> > Collections.reverseOrder(Comparator) as well.
> >
> > Hen
> >
> > > I agree that reverse is common terminology when sorting, but I disagree
> > > that sorting is intrinsicly what a comparator does. While sorting is
> > > probably the most common use-case for comparators, the comparator itself
> > > does not do any sorting. It compares objects and returns a negative,
> zero
> > > value, or positive result. It doesn't rearrange, reverse, order, or
> > > "sort". It just compares two objects. This particular comparator
> > > "inverses" the result of the compare to be a positive, zero value, or
> > > negative result (respectively). I use "inverse" here in its
> mathematical
> > > sense of inverting the result, since that's all this comparator is
> doing.
> > >
> > > I'm not going to argue this anymore though. I've changed my position --
> > > why is this class even included in commons when the JDK provides a
> > > reverse/inverse comparator already? @see Collections.reverseOrder()
> > >
> > > regards,
> > > michael
> > >
> > > > "Michael A. Smith" wrote:
> > > > >[snip]
> > > > > Additionally, I think that "InverseComparator" is a more appropriate
> name,
> > > > > as "inverse" has a more direct meaning (to me at least). Inverse
> has the
> > > > > mathematical meaning of the opposite sign which is exactly what this
> > > > > comparator does. Reverse, on the other hand, implies switching the
> order
> > > > > of something, the comparator isn't really switching the order
> (although a
> > > > > collection using the comparator may be "reversed" if it uses the
> "inverse"
> > > > > comparator).
> > > > >
> > > > > Thoughts?
> > > > >[snip]
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Morgan Delagrange <md...@yahoo.com>.
Michael suggested that the no-op constructor essentially behave like this:
ReverseComparator() {
this(ComparableComparator.getInstance());
}
What do you think, Hen? Do you think that is preferable, or do you prefer
your initial behaviour (reversing the List).
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, March 19, 2002 7:50 AM
Subject: Re: [collections] ReverseComparator
>
> I'm happy with the name Inverse as it is more what the comparator does.
> Reverse makes it easier to see how it can be used for one case, but will
> hide other meanings.
>
> Why does this exist over Collections.reverseOrder? Because the Sun version
> is limited. Why can I only reverse Comparables? Really there should be a
> Collections.reverseOrder(Comparator) as well.
>
> Hen
>
> > I agree that reverse is common terminology when sorting, but I disagree
> > that sorting is intrinsicly what a comparator does. While sorting is
> > probably the most common use-case for comparators, the comparator itself
> > does not do any sorting. It compares objects and returns a negative,
zero
> > value, or positive result. It doesn't rearrange, reverse, order, or
> > "sort". It just compares two objects. This particular comparator
> > "inverses" the result of the compare to be a positive, zero value, or
> > negative result (respectively). I use "inverse" here in its
mathematical
> > sense of inverting the result, since that's all this comparator is
doing.
> >
> > I'm not going to argue this anymore though. I've changed my position --
> > why is this class even included in commons when the JDK provides a
> > reverse/inverse comparator already? @see Collections.reverseOrder()
> >
> > regards,
> > michael
> >
> > > "Michael A. Smith" wrote:
> > > >[snip]
> > > > Additionally, I think that "InverseComparator" is a more appropriate
name,
> > > > as "inverse" has a more direct meaning (to me at least). Inverse
has the
> > > > mathematical meaning of the opposite sign which is exactly what this
> > > > comparator does. Reverse, on the other hand, implies switching the
order
> > > > of something, the comparator isn't really switching the order
(although a
> > > > collection using the comparator may be "reversed" if it uses the
"inverse"
> > > > comparator).
> > > >
> > > > Thoughts?
> > > >[snip]
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Henri Yandell <ba...@generationjava.com>.
I'm happy with the name Inverse as it is more what the comparator does.
Reverse makes it easier to see how it can be used for one case, but will
hide other meanings.
Why does this exist over Collections.reverseOrder? Because the Sun version
is limited. Why can I only reverse Comparables? Really there should be a
Collections.reverseOrder(Comparator) as well.
Hen
> I agree that reverse is common terminology when sorting, but I disagree
> that sorting is intrinsicly what a comparator does. While sorting is
> probably the most common use-case for comparators, the comparator itself
> does not do any sorting. It compares objects and returns a negative, zero
> value, or positive result. It doesn't rearrange, reverse, order, or
> "sort". It just compares two objects. This particular comparator
> "inverses" the result of the compare to be a positive, zero value, or
> negative result (respectively). I use "inverse" here in its mathematical
> sense of inverting the result, since that's all this comparator is doing.
>
> I'm not going to argue this anymore though. I've changed my position --
> why is this class even included in commons when the JDK provides a
> reverse/inverse comparator already? @see Collections.reverseOrder()
>
> regards,
> michael
>
> > "Michael A. Smith" wrote:
> > >[snip]
> > > Additionally, I think that "InverseComparator" is a more appropriate name,
> > > as "inverse" has a more direct meaning (to me at least). Inverse has the
> > > mathematical meaning of the opposite sign which is exactly what this
> > > comparator does. Reverse, on the other hand, implies switching the order
> > > of something, the comparator isn't really switching the order (although a
> > > collection using the comparator may be "reversed" if it uses the "inverse"
> > > comparator).
> > >
> > > Thoughts?
> > >[snip]
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by "Michael A. Smith" <ma...@apache.org>.
On Tue, 19 Mar 2002, Christoph Reck wrote:
> In sorting "reverse" is a common terminology, the comparator is used to
> sort. Ascending/Descending would be another term but is to much "point
> of view" dependant.
>
> Just my EUR0.02...
I agree that reverse is common terminology when sorting, but I disagree
that sorting is intrinsicly what a comparator does. While sorting is
probably the most common use-case for comparators, the comparator itself
does not do any sorting. It compares objects and returns a negative, zero
value, or positive result. It doesn't rearrange, reverse, order, or
"sort". It just compares two objects. This particular comparator
"inverses" the result of the compare to be a positive, zero value, or
negative result (respectively). I use "inverse" here in its mathematical
sense of inverting the result, since that's all this comparator is doing.
I'm not going to argue this anymore though. I've changed my position --
why is this class even included in commons when the JDK provides a
reverse/inverse comparator already? @see Collections.reverseOrder()
regards,
michael
> "Michael A. Smith" wrote:
> >[snip]
> > Additionally, I think that "InverseComparator" is a more appropriate name,
> > as "inverse" has a more direct meaning (to me at least). Inverse has the
> > mathematical meaning of the opposite sign which is exactly what this
> > comparator does. Reverse, on the other hand, implies switching the order
> > of something, the comparator isn't really switching the order (although a
> > collection using the comparator may be "reversed" if it uses the "inverse"
> > comparator).
> >
> > Thoughts?
> >[snip]
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] ReverseComparator
Posted by Christoph Reck <Ch...@dlr.de>.
In sorting "reverse" is a common terminology, the comparator is used to
sort. Ascending/Descending would be another term but is to much "point
of view" dependant.
Just my EUR0.02...
"Michael A. Smith" wrote:
>[snip]
> Additionally, I think that "InverseComparator" is a more appropriate name,
> as "inverse" has a more direct meaning (to me at least). Inverse has the
> mathematical meaning of the opposite sign which is exactly what this
> comparator does. Reverse, on the other hand, implies switching the order
> of something, the comparator isn't really switching the order (although a
> collection using the comparator may be "reversed" if it uses the "inverse"
> comparator).
>
> Thoughts?
>[snip]
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[collections] ReverseComparator
Posted by "Michael A. Smith" <ma...@apache.org>.
I just noticed that ReverseComparator has a no-arg constructor which
essentially returns "-1" for all comparisons. This is the same as if a
null comparator is passed to the single-arg constructor. Doing so breaks
the contract for a comparator [sgn(compare(x, y)) == -sgn(compare(y, x))].
I think this should be changed to use the object's natural ordering if no
comparator has been specified. More specifically, see my diff below.
Aside: Is there any compelling reason to use -1*comparator.compare(o1,o2)
instead of comparator.compare(o2,o1)? It seems this way eliminates the
multiplication step and should have the same result.
Additionally, I think that "InverseComparator" is a more appropriate name,
as "inverse" has a more direct meaning (to me at least). Inverse has the
mathematical meaning of the opposite sign which is exactly what this
comparator does. Reverse, on the other hand, implies switching the order
of something, the comparator isn't really switching the order (although a
collection using the comparator may be "reversed" if it uses the "inverse"
comparator).
Thoughts?
regards,
Michael
Index: src/java/org/apache/commons/collections/comparators/ReverseComparator.java
===================================================================
RCS file: /home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/comparators/ReverseComparator.java,v
retrieving revision 1.5
diff -u -r1.5 ReverseComparator.java
--- src/java/org/apache/commons/collections/comparators/ReverseComparator.java 1 Mar 2002 19:18:49 -0000 1.5
+++ src/java/org/apache/commons/collections/comparators/ReverseComparator.java 19 Mar 2002 05:09:43 -0000
@@ -75,6 +75,7 @@
* the reverse(List) method of java.util.Collection.
*/
public ReverseComparator() {
+ this(null);
}
/**
@@ -82,15 +83,15 @@
* of the passed in comparator.
*/
public ReverseComparator(Comparator comparator) {
- this.comparator = comparator;
+ if(comparator != null) {
+ this.comparator = comparator;
+ } else {
+ this.comparator = ComparableComparator.getInstance();
+ }
}
public int compare(Object o1, Object o2) {
- if(comparator == null) {
- return -1;
- } else {
- return -1*comparator.compare(o1,o2);
- }
+ return -1*comparator.compare(o1,o2);
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>