Thanks James. I wanted to pull the comparator classes over from Collections as I wanted to still be able to support them (and use internally as I already had ComparableComparator hidden away) without having to deal with all of Collections.
Maybe the answer though is to ignore them in favour of Ordering, much the way we've long ignored the Date API in favour of Joda Time. It looks like: ComparableComparator = Ordering.natural ReverseComparator = Ordering.reverse NullComparator = Ordering.nullsFirst/nullsLast ComparatorChain = Ordering.from + Ordering.compound FixedOrderComparator = Ordering.explicit Hen On Fri, Aug 26, 2011 at 1:40 AM, James Ring <s...@jdns.org> wrote: > Google Guava has Ordering: > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Ordering.html > > It is an incredibly useful class. Some random example of how it's awesome: > > http://www.polygenelubricants.com/2010/10/elegant-comparison-logic-with-guava.html > > Recommend that ComparatorChain.. just do what Ordering does. :) > > On Fri, Aug 26, 2011 at 1:17 AM, Henri Yandell <flame...@gmail.com> wrote: >> Looking at the Collections ComparatorChain class, I think it's >> overcomplicated. >> >> The current API is: >> >> public class ComparatorChain<E> implements Comparator<E>, Serializable { >> public ComparatorChain() { >> public ComparatorChain(Comparator<E> comparator) { >> public ComparatorChain(Comparator<E> comparator, boolean reverse) { >> public ComparatorChain(List<Comparator<E>> list) { >> public ComparatorChain(List<Comparator<E>> list, BitSet bits) { >> public void addComparator(Comparator<E> comparator) { >> public void addComparator(Comparator<E> comparator, boolean reverse) { >> public void setComparator(int index, Comparator<E> comparator) >> throws IndexOutOfBoundsException { >> public void setComparator(int index, Comparator<E> comparator, >> boolean reverse) { >> public void setForwardSort(int index) { >> public void setReverseSort(int index) { >> public int size() { >> public boolean isLocked() { >> public int compare(E o1, E o2) throws UnsupportedOperationException { >> public int hashCode() { >> public boolean equals(Object object) { >> >> The whole reverse notion seems like unnecessary duplication. If you >> wanted such you could wrap a ReverseComparator around the comparator >> before adding. I also think the notion of locking should also go away, >> make these immutable objects. >> >> ie: >> >> >> public class ComparatorChain<E> implements Comparator<E>, Serializable { >> public ComparatorChain(Comparator<E> comparator...) { >> public ComparatorChain(List<Comparator<E>> list) { >> public int size() { >> public int compare(E o1, E o2) { >> public int hashCode() { >> public boolean equals(Object object) { >> >> The constructors could throw exceptions when they contain no >> comparator. Or we could simply return 0 as having no comparators is >> the same as the comparators being exhausted. >> >> Any thoughts on the simpler API? >> >> Should it also implement Iterable as a way to loop through the >> contained comparators? >> >> Hen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
