Object.Equals es virtual, pero Object.operator == no lo usa en C#?

Question

Me golpeó una extraña "asimetría" en C# que realmente no entiendo. Consulte el siguiente código:

using System; 
using System.Diagnostics; 
namespace EqualsExperiment 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      object apple = "apple"; 
      object orange = string.Format("{0}{1}", "ap", "ple"); 
      Console.WriteLine("1"); 
      Debug.Assert(apple.Equals(orange)); 
      Console.WriteLine("2"); 
      Debug.Assert(apple == orange); 
      Console.WriteLine("3"); 
     } 
    } 
} 

Puede ser obvio para todos los gurús de .NET, pero la segunda afirmación falla.

En Java, he aprendido que == es un sinónimo de algo llamado Object.ReferenceEquals aquí. En C#, pensé que Object.operator == usa Object.Equals, que es virtual, por lo que se reemplaza en la clase System.String.

¿Alguien puede explicar por qué la segunda afirmación falla en C#? ¿Cuáles de mis suposiciones son malas?

Answer 1

El operador == no es un sinónimo, es un operador que se define para diferentes tipos.

El operador == se define para cuerdas, y luego se usa realmente el Equals método:

public static bool operator ==(string a, string b) { 
    return Equals(a, b); 
} 

Sin embargo, en su código que no está utilizando el operador de cadenas, que está utilizando en los objetos, entonces lo que obtienes es el operador == definido para objetos, que usa ReferenceEquals para hacer la comparación.

Qué sobrecarga del operador usar se decide en tiempo de compilación, por lo que es el tipo de variables que decide la sobrecarga, no el tipo real de los objetos a los que apuntan las variables.

Answer 2

Los operadores se definen como métodos estáticos, por lo que no pueden participar en el polimorfismo. Por lo tanto, su segunda afirmación usa la definición de == para object (ya que sus variables se declaran como object), que solo prueba la igualdad de referencia. Si las variables se declararon como string, se habría utilizado la sobrecarga == para string, y la segunda afirmación habría tenido éxito.