From: Rick M. <obj...@gm...> - 2007-04-18 21:47:24
|
One of the items that's starting to bubble toward the top of my todo list is sorting. I would like to add sorting to the array class (and potentially list, but that one may be harder to implement efficiently). I'm a real fan of the approach that Sun took with Java, as I think it makes a lot of sense for ooRexx too since it makes no real assumptions on the types of data that can be sorted (i.e., it doesn't assume that everything is necessarily a string). In the Java world, you can sort two ways. One way is to sort an array of objects that implement the Comparable interface. A Comparable object implements a comparison (compareTo) method where it is given a reference to another object and asked to compare itself to the other object. The return values from comparable are positive number, zero, negative number representing the states greater than, equal, and less than. Not surprisingly, the String class implements comparable, so it is a simple matter to sort an array of strings. The other way to sort is to invoke the sort using a Comparator. A comparator object nows how to perform a comparison on two objects. For example, if you wanted to do a caseless string sort, you'd write a simple comparator that called the string compareToIgnoreCase() method rather than compareTo(). A very simple, yet very powerful framework. I want to do something similar. I just have two concerns that I feel should be discussed: 1) What should be the return values from the comparison methods? We need a 3-value return, so .true/.false don't really work. The positive/zero/negative method seems to C/C++ish to me, but will work. We could return a character value...perhaps ">", "=", and "<". I'm open to any suggestions on this front, including settling with positive/zero/negative. If we return specific tokens, it might be nice to make them "dot" environment constants like .true and .false. 2) What should we call the method? Rexx already has a Compare method. The Java compareTo() works, and we'd have a caseless[whatever] version of this, keeping with the naming convention we've been following for caseless stuff. Again, I'm seriously open to suggestion on this as well. Rick |