On Oct 02, 2006, at 23:48 UTC, Karen wrote: > > I'd love to see something like a standard Comparable interface too, but > > there are seriously ugly devils in the details of that. (Just think: > > what exactly would be the parameter types of the Operator_Compare > > function it defines?) > > But why would sorting an object array (which is what we are speaking > of here) have to use operator convert under the hood?
I didn't say operator convert; I said operator compare. > Would it likely > be that big a deal to make object sorting a special case directly > call the Comparable Compare method? Right. I assume that's what Comparable would define: the Operator_Compare method. But the trouble is, how do you define this in a strongly typed fashion? You can't. So you end up being able to compare any Comparable to any other, which is not generally valid. Which is greater: October 15, 2004, or a 4-pound orange? It doesn't make sense. > It's not hard to use for relatively simple sorts, but if the object > array is large and involes 2 or 3 object fields, having to do a first > pass to create the string array could be relatively costly, no? No, not compared to the sorting itself. No matter how many object fields are involved, that first pass is an O(N) operation. The sort is significantly more complex -- probably O(N log(N)) at best. So it will dominate the total time for all but the tiniest arrays (where it doesn't really matter anyway, in most cases). > Or would that likely not be significant because of the overhead of > calling the Compare method each time in the sort? Well yes, then there's that too. Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] Verified Express, LLC "Making the Internet a Better Place" http://www.verex.com/ _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
