2010-09-23 13 views
6

Las uniones discriminadas y otros tipos primitivos en F # utilizan la igualdad estructural por defecto y proporcionan una anulación generada para el método .Equals. El operador de igualdad F # aparentemente difiere del C# en que usa el método .Equals incluso para los tipos de referencia, pero cuando se usan las uniones F # discriminadas desde C#, se utiliza el operador predeterminado == para el objeto, que busca la igualdad de referencia en lugar de igualdad estructural¿Por qué F # no proporciona una sobrecarga personalizada para el operador ==?

¿Por qué F # no genera un operador personalizado == para tipos de unión discriminados, de modo que == da el comportamiento esperado cuando se usa en otros lenguajes .NET?

Respuesta

1

Dicho comportamiento se define por el idioma que está utilizando y no por el idioma de origen del tipo que está utilizando.

+0

Pero, sin duda, == operador debe ser visto como un concepto .NET en lugar de un concepto # C y F # tiene que jugar bien con el resto de .NET ... – SoftMemes

+0

El operador == '' es una Cosa C#. Utilizaron diferentes nombres ('=' vs '==') precisamente porque hacen cosas diferentes, y se hereda de OCaml, que lo hizo. –

+0

@Jon: si bien es cierto, el equipo de F # se aseguró de que los operadores aritméticos comunes funcionaran en todos los idiomas (por ejemplo, '(+)' se traduce a 'op_Addition', que es lo que C# reconoce). Podrían haber generado un método 'op_Equality' con la misma facilidad. – kvb

0

no estoy en el # equipo de F, así que sólo puedo especular, pero aquí son algunas de las razones posibles:

  1. Si desea utilizar la igualdad estructural desde el interior de C#, sólo puede utilizar el Equals método. C# proporciona formas de evaluar dos tipos distintos de igualdad: ¿por qué F # los obliga a comportarse de la misma manera cuando a prefieren usar la igualdad de referencia?
  2. Si desea forzar C# para utilizar la igualdad estructural, es fácil hacerlo usted mismo:

    type T = A | B of int with 
        static member op_Equality(t:T,t2:T) = t = t2 
        // or even static member (=)(t:T, t2:T) = t = t2 
    
  3. Hay un costo de desarrollo de cualquier característica, por lo que incluso si hubiera un claro beneficio para la generación automática de una op_Equality, podría haberse descartado a favor de características de mayor prioridad.

+0

1. Sí, pero == no siempre es igualdad de referencia, object.ReferenceEquals is. C# usa la igualdad de valores para == donde tiene sentido, como para cadenas (que es un tipo de referencia pero sí una comparación de valores cuando se usa ==). – SoftMemes

+0

Curiosamente, de acuerdo con Reflector, 'Object.ReferenceEquals' simplemente llama a' == '. –

+0

@Joel: está bien, ya que los argumentos se tipan estáticamente como objeto, lo que significa que los objetos que acepten operator == siempre se usarán, incluso si el tipo de tiempo de ejecución es algo completamente diferente. – SoftMemes

Cuestiones relacionadas