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
