Почему F # не предоставляет настраиваемую перегрузку для operator ==?

Дискриминированные объединения и другие примитивные типы в F # по умолчанию используют структурное равенство и предоставляют сгенерированное переопределение для метода .Equals. Оператор равенства F #, по-видимому, отличается от оператора C # тем, что он использует метод .Equals даже для ссылочных типов, но когда размеченные объединения F # используются из C #, используется оператор по умолчанию == для объекта, который проверяет ссылочное равенство, а не структурное равенство.

Почему F # не генерирует пользовательский оператор == для размеченных типов объединения, чтобы == давало ожидаемое поведение при использовании в других языках .NET?


person SoftMemes    schedule 23.09.2010    source источник


Ответы (2)


Такое поведение определяется языком, который вы используете, а не языком происхождения используемого вами типа.

person J D    schedule 23.09.2010
comment
Но, безусловно, оператор == следует рассматривать как концепцию .NET, а не концепцию C #, а F # должен хорошо работать с остальной частью .NET ... - person SoftMemes; 23.09.2010
comment
Оператор == - это вещь C #. Они использовали разные имена (= vs ==) именно потому, что они делают разные вещи, и это унаследовано от OCaml, который это сделал. - person J D; 23.09.2010
comment
@Jon - хотя это правда, команда F # убедилась, что общие арифметические операторы работают на разных языках (например, (+) переводится в op_Addition, что и распознает C #). Они могли бы так же легко создать op_Equality метод. - person kvb; 23.09.2010
comment
@kvb: Вы имеете в виду собственные числовые типы F #, такие как векторы и матрицы? - person J D; 24.09.2010
comment
@Jon: Нет, я имею в виду, что если вы создаете определение типа type T() = static member (+)(_:T,_:T) = T(), вы также должны иметь возможность использовать оператор + в экземплярах T в C #. Это работает, потому что скомпилированная форма F # создает статический метод с именем op_Addition, который также является тем, как C # перегружает оператор +. - person kvb; 24.09.2010
comment
@kvb: Понятно. Предположительно, это было сочтено нормальным, потому что это не заменяло существующие функциональные возможности C #. - person J D; 24.09.2010

Я не в команде F #, поэтому могу только предполагать, но вот несколько возможных причин:

  1. Если вы хотите использовать структурное равенство из C #, вы можете просто использовать метод Equals. C # предоставляет способы проверки двух различных видов равенства - почему F # должен заставлять их вести себя одинаково, если a может предпочесть возможность использования ссылочного равенства?
  2. Если вы хотите заставить C # использовать структурное равенство, это легко сделать самостоятельно:

    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. Любая функция требует затрат на разработку, поэтому даже если бы была очевидная выгода от автоматического создания op_Equality, ее можно было бы отбросить в пользу функций с более высоким приоритетом.

person kvb    schedule 23.09.2010
comment
1. Да, но == не всегда является равенством ссылок, а object.ReferenceEquals - это. C # действительно использует равенство значений для == там, где это имеет смысл, например, для строк (который является ссылочным типом, но выполняет сравнение значений при использовании ==). - person SoftMemes; 23.09.2010
comment
Что интересно, согласно Reflector, Object.ReferenceEquals просто вызывает ==. - person Joel Mueller; 23.09.2010
comment
@Joel - это нормально, поскольку аргументы статически типизированы как объект, что означает, что всегда будет использоваться оператор ==, принимающий объекты, даже если тип среды выполнения является чем-то совершенно другим. - person SoftMemes; 23.09.2010
comment
@Freed - я не обязательно не согласен; Я думаю, что у любого подхода есть свои плюсы и минусы. Честно говоря, мне не очень нравится, как ведет себя оператор == в C # - слишком легко по ошибке вернуться к ссылочному равенству. Я думаю, что использование Equals почти всегда лучший выбор, и это будет хорошо работать для типов F #. - person kvb; 23.09.2010