[Mono-bugs] [Bug 76698][Nor] Changed - Array.Sort <T> not implemented

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Wed Dec 7 04:55:26 EST 2005


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by carlos at unixmexico.org.

http://bugzilla.ximian.com/show_bug.cgi?id=76698

--- shadow/76698	2005-12-07 04:48:17.000000000 -0500
+++ shadow/76698.tmp.17059	2005-12-07 04:55:26.000000000 -0500
@@ -44,6 +44,34 @@
 patch by weekend.
 
 ------- Additional Comments From carlos at unixmexico.org  2005-12-07 04:48 -------
 Created an attachment (id=16183)
 Proposed patch
 
+
+------- Additional Comments From carlos at unixmexico.org  2005-12-07 04:55 -------
+Hey, the attached patch implements the generic version of Array.Sort.
+The important thing here is around this section (inside Array.compare<T>):
+
+if (value1 is IComparable)
+   return ((IComparable) value1).CompareTo (value2);
+else
+   return ((IComparable<T>) value1).CompareTo (value2);
+
+This way it works fine and passed al the Array tests (generic and
+non-generic ones). However, usually if you have a class that
+implements both IComparable and IComparable<T>, you want this last one
+to be used. The problem is that the runtime confuses when trying to do
+something like 'obj is IComparable<object>', so some weird problems
+appear in very particular cases.
+
+So I kept the order of the check inverted, so the sort works fine.
+Later, when the bug is fixed, we can invert again this check. We would
+have something like:
+
+if (value is IComparable<T>)
+ (IComparable<T>) value...
+else
+ (IComparable> value...
+
+Carlos.
+


More information about the mono-bugs mailing list