[Mono-bugs] [Bug 43359][Wis] Changed - Overloaded method selection doesn't follow ECMA spec

bugzilla-daemon@rocky.ximian.com bugzilla-daemon@rocky.ximian.com
Fri, 23 May 2003 05:14:20 -0400 (EDT)


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 skeet@pobox.com.

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

--- shadow/43359	Thu May 22 10:55:03 2003
+++ shadow/43359.tmp.7296	Fri May 23 05:14:20 2003
@@ -169,6 +169,33 @@
 Thanks for bringing this to our attention.
 
 Miguel.
 
 ------- Additional Comments From ravi@ximian.com  2003-05-22 10:55 -------
 I am marking this as WONTFIX for now
+
+------- Additional Comments From skeet@pobox.com  2003-05-23 05:14 -------
+Oops - it looks like this (the first problem posted) isn't a bug after
+all. Looking at ECMA section 14.5.5.1, we get:
+
+<quote>
+The set of candidate methods for the method invocation is constructed.
+Starting with the set of methods associated with M, which were found
+by a previous member lookup (§14.3), the set is reduced to those
+methods that are applicable with respect to the argument list A. The
+set reduction consists of applying the following rules to each method
+T.N in the set, where T is the type in which the method N is declared:
+
+* If N is not applicable with respect to A (§14.4.2.1), then N is
+removed from the set.
+* If N is applicable with respect to A (§14.4.2.1), then all methods
+declared in a base type of T are removed from the set. 
+</quote>
+
+The last bullet is the relevant one. Shame it's not more obvious
+elsewhere!
+
+Anyway, that draws the original bug to a close, I believe. Whether or
+not you want to emulate csc's broken (I still think) behaviour in the
+previous post I made, where the base class's method is overridden in
+the derived class and the *derived* version is removed, I don't know.
+