On 5/28/07, Rony G. Flatscher <Rony.Flatscher@wu-wien.ac.at> wrote:

No, it cannot.  The ColumnComparator should be symmetric in it's results regardless of the order of the arguments.  Defaulting the length to the length of one or the other argument can result in inconsistent results if the strings being compared happen to be of different lengths.  The length needs to be specified.
Then how about defaulting the length to something like "5" or "10"? This would define a default length, if omitted, but would allow the coder to omit the argument altogether. (Even if the coder supplies a length, it could always be the case that two compared strings are of different lengths, such that for some comparisons, column+length exceeds the length of one of the strings.)

So this would probably mean that:
  • class "ColumnComparator":
    • method "compare" is missing
Hmmm, I wonder how that happened...it was certainly working correctly at the symposium.  Please open a bug report.
Will do.
    • should mixinclass "Comparator"
I disagree.  

  • class "CaselessColumnComparator":
    • should mixinclass "Comparator"
I disagree.

  • class "InvertingComparator":
    • in method "compare": "USE STRICT ARG left, rightis missing
Where's the bug report.
Will do.
    • should mixinclass "Comparator"

I disagree.
Well, the "mixinclass comparator" follows from the observation that you already do a mixinclass of comparator for "DescendingComparator", "CaselessComparator" and "DescendingCaselessComparator".

To be able to fully use the classification tree for classifying purposes, the classes "Comparator" and "DescendingComparator" should both have either the same parent, or "DescendingComparator" should specialize "Comparator" or both classes should be marked with a class that indicates "comparator" functionality. (An alternative could be to use a package concept, where one would be able to classify by putting classes belonging together into the same package; but then one would need an ability to check whether a class got defined to belong to a certain package.)

I'm not convinced this is a useful classification for these.  There is not requirement that any comparator object implement either of these....the object just needs to implement the compare method to function.
Not tying "ColumnComparator", "CaselessColumnComparator" and "InvertingComparator" to "Comparator" as a mixinclass seems not to be logical. Or with other words, if you disagree with tying these classes to "Comparator", what is your reasoning for mixinclassing the other comparator classes to "Comparator"?

Ok, I'll concede this point...that's what I get for answering the questions without access to the source :-)


Cf. the current class hierarchy as depicted in the reference card at: <http://wi.wu-wien.ac.at/rgf/rexx/misc/refCard/ooRexx-3-2-planned.pdf> . You'll see that most Comparator classes are nicely grouped underneath the "Comparator" class, but the Column comparators and invertingComparator are not.

Of course, in addition and independently of organizing these "comparator" classes (all just possessing "compare" and possibly a constructor method) any class should qualify as a comparator class, as long as it implements the "compare" method. (My suggested sort-method implementation just checks for the existence of that method.) [Such a class could be "nice" by inheriting from the "Comparator" class to document this fact explicitly.]


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Oorexx-devel mailing list