DO NOT REPLY [Bug 16823] New: - Add a fixed order Comparator

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16823>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16823

Add a fixed order Comparator

           Summary: Add a fixed order Comparator
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Collections
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: david@leppik.net


Among the simple classes I use frequently is a Comparator which imposes a fixed
and arbitrary order on a group of objects.  As with so many things, it's not
hard to coerce this behavior, but it's really convenient to have a class which
does it for you.  It's also something that can be hard to live without once you
have it, assuming the appropriate problem space.  (Then again, what isn't?)

I wrote such a class for my current employer (http://www.vocalabs.com) which has
graciously given me permission to donate it and its unit tests to Commons, as
well as spend work hours on this project.  It will need some cleaning up (add
the Apache copyright, probably change the name, and tighten error handling),
which I am prepared to do.

If others consider this valuable, I'd like some advice on how to proceed to best
integrate it into Commons.  But first some details.

The class is currently named MapOrderComparator, since it uses a map to enforce
the underlying order.  I don't like the name because it obscures its purpose. 
I'm still fishing for a better name; FixedOrderComparator and/or
ArbitraryComparator don't get the point across, though.  A sample usage is as
follows:

    String[] days = { "Monday", "Tuesday", "Wednesday", /* etc...*/ };

    /* Construct a Comparator which uses the order of the array */
    Comparator dayComparator = new MapOrderComparator(days);

    TreeMap stuffThatHappensDuringTheWeek = new TreeMap(dayComparator);

    myThingie.populate(stuffThatHappensDuringTheWeek);
    myViewer.displaySomeMappedData(stuffThatHappensDuringTheWeek);


I wrote the class to do arbitrary order comparisons, using a Map implementation,
but included some general-purpose Map functionality, including a constructor
which takes a Map.  I've never populated the map values with anything other than
Integers to keep track of the initial order.  So one way to proceed would be to
hide the Map as an implementation detail.

Another way to proceed would be to treat it as an 
org.apache.commons.collections.comparators.TransformingComparator.  In fact,
when I first saw the TransformingComparator, I thought it would be a good
replacement for the MapOrderComparator.  Unfortunately, usage is more awkward
and it doesn't do the right thing out-of-the-box.

The TransformingComparator takes an org.apache.commons.collections.Transformer
and a Comparator (typically a ComparableComparator).  Transformer is an
interface, and other than org.apache.cocoon.transformation.TraxTransformer
 I can't find any classes which implement it.  What you'd want is a
CountingTransformer, which transfomrs Objects into Integers.

Given a CountingTransformer, the above code could be rewritten as:

<   Comparator dayComparator = new MapOrderComparator(days);
-
>   Transformer daysToIntegers = new CountingTransformer(days);
>   Comparator dayComparator 
>       = new TransformingComparator(daysToIntegers);

This approach gets the job done just as well, if slightly more verbosely.  It's
 the best integrated with the existing classes, but harder to find.  (I wouldn't
go looking for a CountingTransformer if I needed a Comparator.)  The classes I'm
propopsing are trivial to code, so their value depends on (1) being easier to
find than to write, and (2) inspiring simple solutions which are only obvious
from awareness of the class.

Thus the second way to proceed would be for me to submit a CountingTransformer,
perhaps noting its existance in the TransformingComparator javadoc.

I welcome advice and opinions on how to proceed.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org