Dreamora:
I still don't understand where you are coming from.
You say my compare method is bad. Well create an example for me where MY compare method breaks, so I can see what it is you are saying is wrong about my method.
I've shown you how your example breaks. "For the same values, there is no rule on "how they are sorted" as I was not interested in their internal ordering." doesn't cut it.
A Bubble sort by definition is invariant. Mark's bubble sort is invariant when using my compare method. It is not invariant when using your compare method. Your compare method therefore is not compatible with Mark's bubble sort. It clearly does not return the values Mark's bubble sort expects it to return.
And if it doesn't return the values MARK expects it to return, how can you possibly say it is the correct way to implement it? Wouldn't MARK know best how it is supposed to work? Wouldn't Marks OWN compare methods implemented in his own types return the correct values?
Here is how Mark has implemented compare functions in HIS OWN TYPES:
win32gui.bmx:
data.bmx:
cocoamaxgui:
And the last one, which is the only one which is different:
fltkgui.bmx:
This one is different because it's comparing strings, and converts the strings to lowercase before comparison. It's still returning -1 0 or 1 if the strings are less than equal or greater than one another. None of that pointer funny business.
Those four examples comprise every single compare method Mark implemented in the max code. Not one is like your own.
So again, I ask how you can say your method is correct when the author of the language, who should know better than you how it works, uses a different method from yours?
I still don't understand where you are coming from.
You say my compare method is bad. Well create an example for me where MY compare method breaks, so I can see what it is you are saying is wrong about my method.
I've shown you how your example breaks. "For the same values, there is no rule on "how they are sorted" as I was not interested in their internal ordering." doesn't cut it.
A Bubble sort by definition is invariant. Mark's bubble sort is invariant when using my compare method. It is not invariant when using your compare method. Your compare method therefore is not compatible with Mark's bubble sort. It clearly does not return the values Mark's bubble sort expects it to return.
And if it doesn't return the values MARK expects it to return, how can you possibly say it is the correct way to implement it? Wouldn't MARK know best how it is supposed to work? Wouldn't Marks OWN compare methods implemented in his own types return the correct values?
Here is how Mark has implemented compare functions in HIS OWN TYPES:
win32gui.bmx:
Type TIntWrapper Field value Method Compare(o:Object) Return value-TIntWrapper(o).value End Method
data.bmx:
Type TDataId Field id Method Compare( with:Object ) Return id-TDataId(with).id End Method
cocoamaxgui:
Type TIntWrapper Field value Method Compare(o:Object) Return value-TIntWrapper(o).value End Method
And the last one, which is the only one which is different:
fltkgui.bmx:
Type TFLFont Field name$,ids[4],sizes[] Method Compare( o:Object ) Local f:TFLFont=TFLFont(o) Assert f Return name.ToLower().Compare( f.name.ToLower() ) End Method
This one is different because it's comparing strings, and converts the strings to lowercase before comparison. It's still returning -1 0 or 1 if the strings are less than equal or greater than one another. None of that pointer funny business.
Those four examples comprise every single compare method Mark implemented in the max code. Not one is like your own.
So again, I ask how you can say your method is correct when the author of the language, who should know better than you how it works, uses a different method from yours?