Tengo la siguiente clase de extensiones:
public static class MatcherExtensions { public static ExecMatcher<T1, T2> Match<T1, T2>(this Tuple<T1, T2> item) { return new ExecMatcher<T1, T2>(item.Item1, item.Item2); } public static ExecMatcher<T1, T2> Match<T1, T2>(this ITupleMatchable<T1, T2> item) { var tuple = item.PropertiesToMatch; return new ExecMatcher<T1, T2>(tuple.Item1, tuple.Item2); } public static ExecMatcher<T> Match<T>(this T item) { return new ExecMatcher<T>(item); } } Si creo una tupla e invoco Match() , utiliza correctamente el primer método de extensión:
var tuple = Tuple.Create(1, "a"); tuple.Match().With(1, "a")... // compiles just fine. Si creo un int e invoco Match() , usa correctamente el último método de extensión:
var one = 1; one.Match().With(1)... // compiles just fine. Sin embargo, si creo SomeClass , que implementa ITupleMatchable<int, string> y trato de hacer coincidir, el compilador aún elige el tercer método de extensión, en lugar del segundo, a pesar de que este último es una coincidencia más específica:
var obj = new SomeClass(1, "a"); obj.Match().With(1, "a")... // won't compile. Basado en la respuesta de Eric Lippert a una pregunta similar , he solucionado esto colocando el tercer método de extensión en su propia clase dentro de un subdirectorio, creando así un espacio de nombres más largo y, por lo tanto, más "distancia" entre él y el código de llamada que para la versión. específico de ITupleMatchable<T1, T2> . Sin embargo, esto se siente como un truco para mí. ¿Hay una forma más ordenada de resolver esto?
Si simplemente lanza new SomeClass(1, "a") a ITupleMatchable<int, string> , funcionará bien:
var obj = (ITupleMatchable<int, string>)new SomeClass(1, "a"); obj.Match().With(1, "a"); Recuerde que, de lo contrario, su variable obj tiene un tipo de tiempo de compilación de SomeClass . El compilador puede hacer coincidir "más fácilmente" la clase real con el tercer método de extensión (que es compatible con cualquier tipo), que al tener que mirar las implementaciones de interfaz de SomeClass y luego hacerla coincidir, por ejemplo, con el segundo método de extensión.
Pero si proporciona this parámetro como el tipo de interfaz real, entonces el segundo método de extensión encaja mejor, porque es exactamente el tipo que busca el método, en lugar de ser el "cualquier tipo" más amplio. Es decir, es una declaración más específica, por lo que es "mejor".
Tenga en cuenta que una vez que se encuentra el conjunto candidato de métodos de extensión (a través de reglas relacionadas con el espacio de nombres, etc.), el método real se determina utilizando la resolución de sobrecarga normal. Es decir, habiendo determinado que al menos un método en su clase MatcherExtensions es un método de extensión elegible, el compilador sigue las reglas normales de resolución de sobrecarga para elegir entre ellos. Puede encontrar esas reglas en la especificación C# 5.0, sección 7.5.3 .
Sin embargo, brevemente: antes de aplicar las reglas de resolución de sobrecarga (de hecho, para determinar qué métodos son elegibles), tenga en cuenta que el compilador ya ha decidido los parámetros de tipo genérico. Entonces, mientras evalúa la resolución de sobrecarga, está mirando Match(SomeClass item) y Match(ITupleMatchable<int, string> item) . Con suerte, una vez que considere eso, verá por qué, si la variable tiene el tipo SomeClass , el compilador elige su tercera extensión preferentemente sobre la segunda, y viceversa si el tipo es ITupleMatchable<int, string> .