Re[16]: override Equals: Nemerle-CSharp - Nemerle

Здравствуйте, Аноним, Вы писали:

А>В действительности в сравнении по ссылке и по значению все намного хуже.

А>Не везде ясно какой из вариантов используется.

Это в C#. В Nemerle как раз всегда известно. В Nemerle сравнение по ссылке допустимо только для типа object, так что попытка использовать == для типов у которых не определен оператор == приведет к выдаче сообщения об ошибке. Если нужно сравнить ссылки то нужно или уточнить тип:

def s1 = "abc";
def s2 = s1;
assert(s1 : object == s2);

или воспользоваться функцией object.ReferenceEquals().

В данном же случае проблема в чем-то другом, так как макрос генерирует один и тот же код. Думаю, что автор темы просто где-то ошибся.

Здравствуйте, para, Вы писали:

P>

P>[StructuralEquality]
P>...
P>// 1. Nemerle
P>a1 == a2      // = true
P>// 2. CSharp
P>a1 == a2      // = false
P>

P>в issues?

Сдается мне ты где-то ошибся. Я поглядел исходный код макроса StructuralEquality:

Скрытый текст

  [Nemerle.MacroUsage (Nemerle.MacroPhase.WithTypedMembers,
                       Nemerle.MacroTargets.Class,
                       Inherited = false, AllowMultiple = false)]
  macro StructuralEquality (tb : TypeBuilder)
  {
    def fields = tb.GetFields(BindingFlags.Public %| BindingFlags.NonPublic %|
                             BindingFlags.Instance %| BindingFlags.DeclaredOnly);

    def invokeEquals(x : IField)
    {
      def nm = Macros.UseSiteSymbol(x.Name);
      if(x.GetMemType().IsValueType)
        <[ $(nm : name).Equals(other.$(nm : name)) ]>
      else
        <[ System.Collections.Generic.EqualityComparer.Default.Equals($(nm : name), other.$(nm : name)) ]>;
    }

    def body = match(fields)
    {
      | []       => <[ true ]>
      | [single] => invokeEquals(single)
      | first :: others =>
        others.FoldLeft(invokeEquals(first), (field, acc) => <[ $acc && $(invokeEquals(field)) ]>)
    }

    tb.Define(<[ decl:
      public override Equals (_ : System.Object) : bool
      {
        | null => false
        | x when x.GetType().Equals(this.GetType()) =>
          def other = x :> $(tb.ParsedTypeName);
          $body
        | _ => false
      }
    ]>);
  }

В нем нет генерации оператора ==. А учитывая, что немерл не позволяет использовать оператор == для типов для которых он не определен, то и пример твой работать не должен.

Я провел смелый научный эксперимент и получил ожидаемый результат:

using Nemerle.Collections;
using Nemerle.Text;
using Nemerle.Utility;

using System;
using System.Collections.Generic;
using System.Console;
using System.Linq;

[StructuralEquality]
public class A{
  i : int;
}

module Program
{
  Main() : void
  {
    def a1 = A();
    def a2 = A();

    WriteLine(a1 == a2); // Error: the custom attribute 'StructuralEquality' could not be found or is invalid
  }
}

Так что ищи ошибку в своем коде.

Здравствуйте, VladD2, Вы писали:

VD>Я провел смелый научный эксперимент и получил ожидаемый результат:
VD>

VD>using Nemerle.Collections;
VD>using Nemerle.Text;
VD>using Nemerle.Utility;

VD>using System;
VD>using System.Collections.Generic;
VD>using System.Console;
VD>using System.Linq;

VD>[StructuralEquality]
VD>public class A{
VD>  i : int;
VD>}

VD>module Program
VD>{
VD>  Main() : void
VD>  {
VD>    def a1 = A();
VD>    def a2 = A();

VD>    WriteLine(a1 == a2); // Error: the custom attribute 'StructuralEquality' could not be found or is invalid
VD>  }
VD>}
VD>

VD>Так что ищи ошибку в своем коде.

Ошибка тут будет: Error: comparing values of types A and A with reference equality
А то, что показано это отсутствие using Nemerle.Extensions;

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Аноним, Вы писали:

А>>В действительности в сравнении по ссылке и по значению все намного хуже.

А>>Не везде ясно какой из вариантов используется.

Z>Например?

Буквально вчера поимел таковую проблему:

var newRoute = new RouteValueDictionary(ViewContext.RouteData.Values);
if (newRoute ["langdir"] == "en")
{
...
}

Nemerle этого бы не допустил и потребовал явного вызова Equals:

var newRoute = new RouteValueDictionary(ViewContext.RouteData.Values);
if ("en".Equals(newRoute["langdir"]))
{
}

Здравствуйте, hardcase, Вы писали:

H>Буквально вчера поимел таковую проблему:
H>

H>var newRoute = new RouteValueDictionary(ViewContext.RouteData.Values);
H>if (newRoute ["langdir"] == "en")
H>{
H>...
H>}
H>

А что конкретно лежало в newRoute["langdir"]? Если это строка то я никаких проблем не вижу, а если другой тип, не пойму чем здесь поможет equals?

Здравствуйте, hardcase, Вы писали:

H>Nemerle этого бы не допустил и потребовал явного вызова Equals:
H>

H>var newRoute = new RouteValueDictionary(ViewContext.RouteData.Values);
H>if ("en".Equals(newRoute["langdir"]))
H>{
H>}
H>

Немерл позволил бы вообще не писать подобный шлак. Написал бы себе обвязочку из макросов и описывал бы весь роутинг декларативно.

Здравствуйте, Ziaw, Вы писали:

Z>А что конкретно лежало в newRoute["langdir"]? Если это строка то я никаких проблем не вижу, а если другой тип, не пойму чем здесь поможет equals?

Строка

Я не знаю что там происходило, но изменение на второй способ сделало код работоспособным.

Здравствуйте, VladD2, Вы писали:

VD>Немерл позволил бы вообще не писать подобный шлак. Написал бы себе обвязочку из макросов и описывал бы весь роутинг декларативно.

Там не роутинг (роутинг на строковых шаблонах в ASP.NET MVC вообще непостижимый какой-то), там модификация текущего маршрута с целью изменения выбранного языка.

Здравствуйте, VladD2, Вы писали:

VD>Сдается мне ты где-то ошибся.

да точно

Здравствуйте, hardcase, Вы писали:

VD>>Немерл позволил бы вообще не писать подобный шлак. Написал бы себе обвязочку из макросов и описывал бы весь роутинг декларативно.

H>Там не роутинг (роутинг на строковых шаблонах в ASP.NET MVC вообще непостижимый какой-то), там модификация текущего маршрута с целью изменения выбранного языка.

Надо бы придумать роутинг на пеге, есть идеи синтаксиса и реализации? Все что не приходит в голову, приводит меня к переписыванию большого куска макроса

Здравствуйте, Ziaw, Вы писали:

Z>Надо бы придумать роутинг на пеге, есть идеи синтаксиса и реализации? Все что не приходит в голову, приводит меня к переписыванию большого куска макроса

А зачем его переписывать? Нужно просто фронт-энд для него новый создавать (это достаточно легко делается), а кишкам макроса отдавать объект Grammar и класс с обработчиками.

Здравствуйте, hardcase, Вы писали:

H>Строка

H>Я не знаю что там происходило, но изменение на второй способ сделало код работоспособным.

Хм... точно. Одинаковые строки могут выдавать по ReferenceEquals как true так и false. Неожиданно, хотя механизм вполне понятен, компилятор строки интернирует, а рантайм, естественно, нет.

Здравствуйте, hardcase, Вы писали:

H>Буквально вчера поимел таковую проблему:
H>

H>var newRoute = new (ViewContext.RouteData.Values);
H>if (newRoute ["langdir"] == "en")
H>{
H>...
H>}
H>

H>Nemerle этого бы не допустил и потребовал явного вызова Equals:

Не потребовал бы. Индексатор RouteValueDictionary возвращает object. А как раз для него в Неперле разрешено использовать == для ссылочной эквивалентности. Ну, и как результат две копии строки будут разными даже если они содержат одно и то же значение.

Здравствуйте, hardcase, Вы писали:

Z>>Надо бы придумать роутинг на пеге, есть идеи синтаксиса и реализации? Все что не приходит в голову, приводит меня к переписыванию большого куска макроса

H>А зачем его переписывать? Нужно просто фронт-энд для него новый создавать (это достаточно легко делается), а кишкам макроса отдавать объект Grammar и класс с обработчиками.

О каком макросе вы ведете речь?

Здравствуйте, VladD2, Вы писали:

Z>>>Надо бы придумать роутинг на пеге, есть идеи синтаксиса и реализации? Все что не приходит в голову, приводит меня к переписыванию большого куска макроса

H>>А зачем его переписывать? Нужно просто фронт-энд для него новый создавать (это достаточно легко делается), а кишкам макроса отдавать объект Grammar и класс с обработчиками.

VD>О каком макросе вы ведете речь?

PegGrammar, грубо говоря нужно научиться давать ему грамматику из другого макроса.

Здравствуйте, Ziaw, Вы писали:

Z>PegGrammar, грубо говоря нужно научиться давать ему грамматику из другого макроса.

Я тебе уже говорил, что ты извращенно мыслишь. Грамматика юрлов одна и та же. Писать разные парсеры для разных путей — это овреркил. Проблема решается в сто раз проще.

Ты просто не представляешь сколько PegGrammar может нагенерировать кода. Его компиляция будет занимать времени во много раз больше нежели будет нужно для сборки основного кода проекта.

Здравствуйте, VladD2, Вы писали:

VD>Я тебе уже говорил, что ты извращенно мыслишь. Грамматика юрлов одна и та же. Писать разные парсеры для разных путей — это овреркил. Проблема решается в сто раз проще.

А ты сам ее решал? Под рукой нет ASP.NET-ных исходников, но в RoR код роутинга это несколько тысяч строк (обычных текстовых, код нечем измерить). Это во первых.

Во вторых, там очень тупой алгоритм, берется урл и проверяется на каждый маршрут из списка, если совпал — вот он наш маршрут, O(N). На очень простеньком RoR сайте у меня сейчас 127 маршрутов. Для оптимизации их количество советуют сокращать, используя универсальный: /{controller}/{action}[/{id}]?params, но мне такой подход не нравится.

Можно конечно придумать макрос попроще, конечный автомат он и есть конечный автомат, но когда уже есть пег...

VD>Ты просто не представляешь сколько PegGrammar может нагенерировать кода. Его компиляция будет занимать времени во много раз больше нежели будет нужно для сборки основного кода проекта.

Это уже другой вопрос. А вообще пока все теории, я не на шутку загружен

Здравствуйте, Ziaw, Вы писали:

Z>Во вторых, там очень тупой алгоритм, берется урл и проверяется на каждый маршрут из списка, если совпал — вот он наш маршрут, O(N). На очень простеньком RoR сайте у меня сейчас 127 маршрутов. Для оптимизации их количество советуют сокращать, используя универсальный: /{controller}/{action}[/{id}]?params, но мне такой подход не нравится.

Давай ты вместо того чтобы придумывать "как сделать" опишешь "что надо сделать" без объяснений реализации. Только форматы данных и их интерпретацию. ОК?

Здравствуйте, VladD2, Вы писали:

VD>Давай ты вместо того чтобы придумывать "как сделать" опишешь "что надо сделать" без объяснений реализации. Только форматы данных и их интерпретацию. ОК?

http://rsdn.ru/forum/web/4157393.1.aspx

Здравствуйте, Ziaw, Вы писали:

VD>>Давай ты вместо того чтобы придумывать "как сделать" опишешь "что надо сделать" без объяснений реализации. Только форматы данных и их интерпретацию. ОК?

Z>http://rsdn.ru/forum/web/4157393.1.aspx

Тут есть какой-то там пример, но совершенно нет никаких объяснений. Хотелось бы услышать полноценную постановку задачи. Что, зачем п т.п.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Ziaw, Вы писали:

VD>>>Давай ты вместо того чтобы придумывать "как сделать" опишешь "что надо сделать" без объяснений реализации. Только форматы данных и их интерпретацию. ОК?

Z>>http://rsdn.ru/forum/web/4157393.1.aspx

VD>Тут есть какой-то там пример, но совершенно нет никаких объяснений. Хотелось бы услышать полноценную постановку задачи. Что, зачем п т.п.

Там форматы данных и их интерпретация.

Нужен диспетчер, который вызовет нужный метод контроллера с нужными параметрами в результате анализа HTTP запроса. Для конфигурации диспетчера нужен удобный DSL, который позволит задавать алгоритмы этого анализа. Алгоритмы простые, некоторые параметры запроса (или их части) задают обработчик, некоторые преобразуются в параметры обработчика, каждый конкретный алгоритм называется маршрутом.

Этот же DSL должен генерировать методы, которые способны создать url приняв аргументами маршрут и его параметры. Все проверки на сигнатуры методов и типы входных параметров должны производиться на этапе компиляции.

например сопоставив маршрут "get page/$id, p.Show(id)" с методом контроллера:

public Show(int id) : ViewResult
{
}

Получаем для проверки маршрута алгоритм request.Method == "GET" && Regex.IsMatch(request.Path "^/page/(\d+)".

Надеюсь понятно изложил. Текущая реализация не устраивает тем, что имена маршрутов, контроллеров и методов задаются магическими константами, которые проверяются только в рантайме. Тем, что на каждый запрос перебирать сотни регэкспов ни разу не эффективно.

Здравствуйте, Ziaw, Вы писали:

Z>например сопоставив маршрут "get page/$id, p.Show(id)" с методом контроллера:

А можно примеры url-ов для большего понимания?

Z>

Z>public Show(int id) : ViewResult
Z>{
Z>}
Z>

Сдается мне тут слишком много лишней информации. Вот так будет проще "get page/$id -> Show".

Z>Получаем для проверки маршрута алгоритм request.Method == "GET" && Regex.IsMatch(request.Path "^/page/(\d+)".

Хорошо бы описать общий синтаксис такого пути. Обрати внимание, не регекс для отлова конкретного пути, а общий синтаксис пути. Лучше в ПЕГ-нотации.

Z>Надеюсь понятно изложил. Текущая реализация не устраивает тем, что имена маршрутов, контроллеров и методов задаются магическими константами, которые проверяются только в рантайме. Тем, что на каждый запрос перебирать сотни регэкспов ни разу не эффективно.

Опять же хорошо бы видеть примеры текущей реализации и те url-ы которые они описывают.

Здравствуйте, VladD2, Вы писали:

VD>А можно примеры url-ов для большего понимания?

В моем примере все урлы есть.

/page/new
/page/1 (get, put, post, delete)
/page/1/edit
/page/1/attachment/1

VD>Сдается мне тут слишком много лишней информации. Вот так будет проще "get page/$id -> Show".

Непонятно что делать, когда параметров больше, по именам сопоставлять? Вдобавок некоторые параметры могут быть обычными выражениями.

Z>>Получаем для проверки маршрута алгоритм request.Method == "GET" && Regex.IsMatch(request.Path "^/page/(\d+)".

VD>Хорошо бы описать общий синтаксис такого пути. Обрати внимание, не регекс для отлова конкретного пути, а общий синтаксис пути. Лучше в ПЕГ-нотации.

Не понял вопроса. Переложить регэксп на peg? "/page/" number; Пег нужен для общего разбора, в итоге грамматика будет примерно такой (урлы не все, просто пример):

pageNew = "/page/" number "/new";
pageShow = "/page/" number; // вот тут еще нужен некий гвард на HTTP метод, либо делать одно правило на CRUD и проверять метод в обработчике.
pagesIndex = "/pages/" ("/skip/" number ("/take/" number)?)?;

attachmentShow = "/page/" number "/attachment/" number; 

route = pageNew / pageShow/ pageIndex / attachmentShow;

Z>>Надеюсь понятно изложил. Текущая реализация не устраивает тем, что имена маршрутов, контроллеров и методов задаются магическими константами, которые проверяются только в рантайме. Тем, что на каждый запрос перебирать сотни регэкспов ни разу не эффективно.

VD>Опять же хорошо бы видеть примеры текущей реализации и те url-ы которые они описывают.

/page/1/new

routes.MapRoute(
                "PageNew",                                                // Route name
                "/page/{id}/new",                                        // URL with parameters
                new { controller = "Page", action = "New" }  // Parameter defaults
            );

Здравствуйте, Ziaw, Вы писали:

Z>В моем примере все урлы есть.

Z>

Z>/page/new
Z>/page/1 (get, put, post, delete)
Z>/page/1/edit
Z>/page/1/attachment/1

Это как-то очень абстрактно. Не ясно почему "page". Потом что тут значит "(get, put, post, delete)"?

VD>>Сдается мне тут слишком много лишней информации. Вот так будет проще "get page/$id -> Show".

Z>Непонятно что делать, когда параметров больше, по именам сопоставлять?

Есессно. А зачем иначе вообще эти $-ы?

Z>Вдобавок некоторые параметры могут быть обычными выражениями.

Это тоже не продемонстрировано.

Может лучше действовать как в Ur, трактовать все Url как функции с параметрами? Тогда и описывать ничего не надо. Функция помеченная неким атрибутом автоматом становится активным Url. В коде это будет просто вызов функций.

Z>>>Получаем для проверки маршрута алгоритм request.Method == "GET" && Regex.IsMatch(request.Path "^/page/(\d+)".

VD>>Хорошо бы описать общий синтаксис такого пути. Обрати внимание, не регекс для отлова конкретного пути, а общий синтаксис пути. Лучше в ПЕГ-нотации.

Z>Не понял вопроса. Переложить регэксп на peg? "/page/" number; Пег нужен для общего разбора, в итоге грамматика будет примерно такой (урлы не все, просто пример):

Z>

Z>pageNew = "/page/" number "/new";
Z>pageShow = "/page/" number; // вот тут еще нужен некий гвард на HTTP метод, либо делать одно правило на CRUD и проверять метод в обработчике.
Z>pagesIndex = "/pages/" ("/skip/" number ("/take/" number)?)?;

Z>attachmentShow = "/page/" number "/attachment/" number; 

Z>route = pageNew / pageShow/ pageIndex / attachmentShow;
Z>

Z>>>Надеюсь понятно изложил. Текущая реализация не устраивает тем, что имена маршрутов, контроллеров и методов задаются магическими константами, которые проверяются только в рантайме. Тем, что на каждый запрос перебирать сотни регэкспов ни разу не эффективно.

VD>>Опять же хорошо бы видеть примеры текущей реализации и те url-ы которые они описывают.

Z>/page/1/new
Z>

Z>routes.MapRoute(
Z>                "PageNew",                                                // Route name
Z>                "/page/{id}/new",                                        // URL with parameters
Z>                new { controller = "Page", action = "New" }  // Parameter defaults
Z>            );
Z>

Здравствуйте, Ziaw, Вы писали:

Сори, нечайно отправил. Устал к вечеру...

VD>>Хорошо бы описать общий синтаксис такого пути. Обрати внимание, не регекс для отлова конкретного пути, а общий синтаксис пути. Лучше в ПЕГ-нотации.

Z>Не понял вопроса. Переложить регэксп на peg? "/page/" number; Пег нужен для общего разбора, в итоге грамматика будет примерно такой (урлы не все, просто пример):

Блин, ну, я же специально подчеркнул, что меня не интересует концертный путь!

Твои юрлы ведь подчиняются какой-то логике? Вот ее и описал бы. Что за форматы допустимы? Как интерпретируются?

Z>/page/1/new
Z>

Z>routes.MapRoute(
Z>                "PageNew",                                                // Route name
Z>                "/page/{id}/new",                                        // URL with parameters
Z>                new { controller = "Page", action = "New" }  // Parameter defaults
Z>            );
Z>

Как я понимаю — это все вариации на тему вызова функции.

Сдается мне, что вся эта херомантия просто лишняя. Что мы хотим получить? Чтобы при запросе некоторого Url у нас вызвалась некая функция, и при этом чтобы параметры командной строки автоматически преобразовывались в значения параметров? Дык это не сложно автоматически сделать на основании сигнатуры этой самой функции. Имеем, скажем, метод:

[UrlHanler(Method=GET)]
Page(id : int) : XDocument // некоторый тип описывающий что возвращается страница
{
  ...
}

Раз мы все равно вызываем метод, то по нему можно и формировать этот самый

Здравствуйте, VladD2, Вы писали:

VD>Блин, ну, я же специально подчеркнул, что меня не интересует концертный путь!

Я не понимаю твоих вопросов, а зачастую и терминов в которых они задаются. Попробуй выражаться яснее.

VD>Твои юрлы ведь подчиняются какой-то логике? Вот ее и описал бы. Что за форматы допустимы? Как интерпретируются?

Это логика архитектора веб приложения, обычно подчиняется общепринятым REST правилам в CRUD операциях. Роутинг ASP.NET MVC вообще не поддерживает канонический REST, HTTP метод у него не является частью маршрута.

Z>>/page/1/new
Z>>

Z>>routes.MapRoute(
Z>>                "PageNew",                                                // Route name
Z>>                "/page/{id}/new",                                        // URL with parameters
Z>>                new { controller = "Page", action = "New" }  // Parameter defaults
Z>>            );
Z>>

VD>Как я понимаю — это все вариации на тему вызова функции.

Это варианты обработки запроса, стандартный вариант — вызов экшена контроллера.

VD>Сдается мне, что вся эта херомантия просто лишняя. Что мы хотим получить? Чтобы при запросе некоторого Url у нас вызвалась некая функция, и при этом чтобы параметры командной строки автоматически преобразовывались в значения параметров? Дык это не сложно автоматически сделать на основании сигнатуры этой самой функции. Имеем, скажем, метод:
VD>

VD>[UrlHanler(Method=GET)]
VD>Page(id : int) : XDocument // некоторый тип описывающий что возвращается страница
VD>{
VD>  ...
VD>}
VD>

Урлы не должны быть завязаны структуру кода внутри приложения, рефакторинг будет ломать внешние ссылки на твой сайт. Урлы это важная часть внешнего контракта сайта (SEO тоже в теме), а контроллеры лишь деталь реализации.

VD>Раз мы все равно вызываем метод, то по нему можно и формировать этот самый

Тут логическое разделение, во вьюхах мы живем в слое представления и оперируем урлами и маршуртами, в контроллере у нас вызовы функций. В рельсах на каждый маршрут генерируется функция {route_name}_path, и она используется для указания маршрутов, в MVC названия маршрутов строками. Подозреваю, что данная концепция ASP.NET MVC и ROR (да и многих MVC web фреймворков) для тебя будет являться очередной непонятной химией, поэтому сразу скажу, что дискутировать на эту тему не намерен. Профита ноль. Ликбез можно устраивать тем, кому он нужен.

Здравствуйте, VladD2, Вы писали:

VD>Как я понимаю — это все вариации на тему вызова функции.

Не только. В урле может находиться контекстная информация вроде локали сайта: /ru/controller/action

Здравствуйте, VladD2, Вы писали:

VD>В нем нет генерации оператора ==. А учитывая, что немерл не позволяет использовать оператор == для типов для которых он не определен, то и пример твой работать не должен.

А что мешает генерить операторы?

Здравствуйте, _FRED_, Вы писали:

_FR>А что мешает генерить операторы?

А зачем этот оператор для ссылочных типов?

Здравствуйте, hardcase, Вы писали:

_FR>>А что мешает генерить операторы?

H>А зачем этот оператор для ссылочных типов?

А зачем этот оператор определён в System.String?

Нет, конечно, если вы считаете, что общепринятые практики фреймворка для вас неприменимы, то вопросов нет и не будет.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, hardcase, Вы писали:

_FR>>>А что мешает генерить операторы?

H>>А зачем этот оператор для ссылочных типов?

_FR>А зачем этот оператор определён в System.String?

Нет, конечно, если вы считаете, что общепринятые практики фреймворка для вас неприменимы, то вопросов нет и не будет.

походу просто надо сделать РАЗНЫХ 2 оператора сравнения. По значению и по ссылке.

Здравствуйте, _FRED_, Вы писали:

_FR>А зачем этот оператор определён в System.String?

Нет, конечно, если вы считаете, что общепринятые практики фреймворка для вас неприменимы, то вопросов нет и не будет.

Я считаю что оператор сравнения равенства нужен значительно реже нежели автоматическое переопределение метода Equals.

Здравствуйте, Аноним, Вы писали:

_FR>>А зачем этот оператор определён в System.String?

Нет, конечно, если вы считаете, что общепринятые практики фреймворка для вас неприменимы, то вопросов нет и не будет.
А>походу просто надо сделать РАЗНЫХ 2 оператора сравнения. По значению и по ссылке.

Нет, не надо. Из всех общеизвестных [ссылочных] типов (из BCL) в которых переопределено Equals я не знаю ни одного, для экземпляров которого имело бы слысл использовать ссылочное равенство. Интересно было бы взглянуть на такой кейс. Он [конечно же найти можно], думаю, будет очень специфическим, на столько специфическим, что именно в нём и имеет смысл использовать ReferenceEquals.

Более того, в четвёртом фреймворке для многих типов BCL, в которых был переопределён Equals и небыли определены операторы сравнения, такие опрераторы определили (например, System.Type).

Здравствуйте, hardcase, Вы писали:

_FR>>А зачем этот оператор определён в System.String?

Нет, конечно, если вы считаете, что общепринятые практики фреймворка для вас неприменимы, то вопросов нет и не будет.
H>Я считаю что оператор сравнения равенства нужен значительно реже нежели автоматическое переопределение метода Equals.

А какие-нибудь размышоения на эту тему есть?

Можете предложить хоть один не редчайший кейс, когда от типа с переопределённым Equals потребовалось бы ссылочное сравнение? Например, для типа System.Version.

В общем всё понятно. Можно не отвечать.

Здравствуйте, _FRED_, Вы писали:

_FR>Можете предложить хоть один не редчайший кейс, когда от типа с переопределённым Equals потребовалось бы ссылочное сравнение?

Если оператор == не определен, то ссылочное сравнение будет использоваться в Nemerle лишь когда один из операндов имеет тип object.

Я не вижу проблемы с тем что операторы == и != не генерируется автоматически макросом StructuralEquality, они нужны не часто, а в случаях когда нужны их легко написать вручную.
Назови, в свою очередь, причину по которой их стоит автоматически генерировать.

Здравствуйте, hardcase, Вы писали:

VD>>Как я понимаю — это все вариации на тему вызова функции.

H>Не только. В урле может находиться контекстная информация вроде локали сайта: /ru/controller/action

Это ни что иное как параметры.

Здравствуйте, _FRED_, Вы писали:

VD>>В нем нет генерации оператора ==. А учитывая, что немерл не позволяет использовать оператор == для типов для которых он не определен, то и пример твой работать не должен.

_FR>А что мешает генерить операторы?

Ни что не мешает. Просто этот макрос это не делает. Можно сделать некий параметр который будет так же операторы добавлять.

Здравствуйте, hardcase, Вы писали:

_FR>>А что мешает генерить операторы?

H>А зачем этот оператор для ссылочных типов?

Вообще-то перекрывая Equals нужно перекрывать и оператор сравнения. Иначе поведение объекта может оказаться странным.

То что объект ссылочный еще не значит, что его эквивалентность проверяется по ссылке. Простой пример класс string или даже list[T]/option[T].

Здравствуйте, _FRED_, Вы писали:

_FR>Нет, не надо. Из всех общеизвестных [ссылочных] типов (из BCL) в которых переопределено Equals я не знаю ни одного, для экземпляров которого имело бы слысл использовать ссылочное равенство. Интересно было бы взглянуть на такой кейс. Он [конечно же найти можно], думаю, будет очень специфическим, на столько специфическим, что именно в нём и имеет смысл использовать ReferenceEquals.

_FR>Более того, в четвёртом фреймворке для многих типов BCL, в которых был переопределён Equals и небыли определены операторы сравнения, такие опрераторы определили (например, System.Type).

Ну, так во всех гайдлайнах написано, что перекрывая оператор ==, надо за одно перекрывать != и Equals. Я не вижу ни одного разумного объяснения почему те же правила не должны применяться и к Equals с !=.

Так что не ясно что ты вдруг возмутился.

Здравствуйте, VladD2, Вы писали:

VD>Так что не ясно что ты вдруг возмутился.

Ой, сорри. Подумал, что это письмо Хардкейса. В общем, я в данном случае на твоей стороне.

Здравствуйте, hardcase, Вы писали:

H>Я не вижу проблемы с тем что операторы == и != не генерируется автоматически макросом StructuralEquality, они нужны не часто, а в случаях когда нужны их легко написать вручную.
H>Назови, в свою очередь, причину по которой их стоит автоматически генерировать.

Немерл уберегает от ряда ошибок по случайности. Это конечно хорошо. Но плохого в генерации операторов я тоже ничего не вижу. Это логично. Да и если класс будет использоваться из шарпа, то кого-то это убережет от ошибок.

Здравствуйте, VladD2, Вы писали:

_FR>>Более того, в четвёртом фреймворке для многих типов BCL, в которых был переопределён Equals и небыли определены операторы сравнения, такие опрераторы определили (например, System.Type).

VD>Ну, так во всех гайдлайнах написано, что перекрывая оператор ==, надо за одно перекрывать != и Equals. Я не вижу ни одного разумного объяснения почему те же правила не должны применяться и к Equals с !=.
VD>Так что не ясно что ты вдруг возмутился.

Это скорее недоумеваниме. Возмущаться неиззачего :о) я возмущался на классы BCL с перееханным equals и без операторов, да они исправляются

Мне непонятно, почему имея весьма полезный макрос вы не довели его до ума, добавив в него и генерацию операторов. Потому что помешать это не сможет никогда, а вот вызвать привести к ошибкам — ещё как. Я правильно из обсуждения уловил, что в Немерле x == y — это вызов Equals(x, y) и оператор натураольный оператор типа просто не используется? Так надо же думать и о других языках и недоумение из-за этого.

Если есть сомнения в том, что при перееханном Equals операторы _необхъодимы_, подумайте хорошенько, когда они не необходимы. Это раз. Второе: а будут ли они когда-нибудь полезны? Ответы на эти два вопроса меня напри мер убеждают в том, что операторы должы быть всегда, когда переопределён Equals, что бы логика операторов и Object.Equals(object, object) была бы одинакова.

Здравствуйте, VladD2, Вы писали:

VD>>>В нем нет генерации оператора ==. А учитывая, что немерл не позволяет использовать оператор == для типов для которых он не определен, то и пример твой работать не должен.
_FR>>А что мешает генерить операторы?

VD>Ни что не мешает. Просто этот макрос это не делает. Можно сделать некий параметр который будет так же операторы добавлять.

Если хочешь, давай тут обсудим, когда эти операторы не будут нужны. И таких кейсов попросту не знаю. Если вы их знаете, скажите. Прошу уже не первый раз в этом топике

Здравствуйте, _FRED_, Вы писали:

_FR>Мне непонятно, почему имея весьма полезный макрос вы не довели его до ума, добавив в него и генерацию операторов.

Потому что никому это не требовалось.

_FR>Я правильно из обсуждения уловил, что в Немерле x == y — это вызов Equals(x, y) и оператор натураольный оператор типа просто не используется?

Нет. Оператор == вызывается только если он определен, в противном случае — ошибка компиляции. Исключением являются случаи когда тип x или y зафиксирован System.Object — в этом случае выполняется сравнение ссылок.

Здравствуйте, hardcase, Вы писали:

_FR>>Мне непонятно, почему имея весьма полезный макрос вы не довели его до ума, добавив в него и генерацию операторов.
H>Потому что никому это не требовалось.

ОК, это уже разумнее ответ, чем "это не нужно".

_FR>>Я правильно из обсуждения уловил, что в Немерле x == y — это вызов Equals(x, y) и оператор натураольный оператор типа просто не используется?
H>Нет. Оператор == вызывается только если он определен, в противном случае — ошибка компиляции. Исключением являются случаи когда тип x или y зафиксирован System.Object — в этом случае выполняется сравнение ссылок.

Ага, понятно. Неужели так редко требуется переопределять == что "никому это не требовалось"?

Неужели это из-за ПМ просто сравнение стало не нужно? Или в проверках на null, например, литеру "null" компилятор типизтрует как System.Object и сравнивает ссылки?

Здравствуйте, _FRED_, Вы писали:

_FR>Ага, понятно. Неужели так редко требуется переопределять == что "никому это не требовалось"?

Да не так уж часто. К тому же как верно заметил Хардкейс оператор ведь пишется в пару строк. Вот всем и было наплевать.

_FR>Неужели это из-за ПМ просто сравнение стало не нужно?

ПМ тут в общем-то не причем.

_FR>Или в проверках на null, например, литеру "null" компилятор типизтрует как System.Object и сравнивает ссылки?

Если оператор не определен, то да. Иначе вызывается оператор (как в шарпе). Хотя может быть как раз было бы удобнее при этом применять ссылочную эквивалентность. Я что-то не могу придумать осмысленного случая сравнения с null.

Неужели это из-за ПМ просто сравнение стало не нужно? Или в проверках на null, например, литеру "null" компилятор типизтрует как System.Object и сравнивает ссылки?

Литерал null типизируется как System.Object, потому код "нечто == null" будет сравнением ссылок.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, hardcase, Вы писали:

H>>Строка

H>>Я не знаю что там происходило, но изменение на второй способ сделало код работоспособным.

Z>Хм... точно. Одинаковые строки могут выдавать по ReferenceEquals как true так и false. Неожиданно, хотя механизм вполне понятен, компилятор строки интернирует, а рантайм, естественно, нет.

Но ведь в строки перегружен оператор ==

Здравствуйте, hardcase, Вы писали:

H>Литерал null типизируется как System.Object, потому код "нечто == null" будет сравнением ссылок.

При условии что у типа "нечто" не определен оператор ==.

Здравствуйте, BogdanMart, Вы писали:

H>>>Строка

H>>>Я не знаю что там происходило, но изменение на второй способ сделало код работоспособным.

Z>>Хм... точно. Одинаковые строки могут выдавать по ReferenceEquals как true так и false. Неожиданно, хотя механизм вполне понятен, компилятор строки интернирует, а рантайм, естественно, нет.
BM>

Но ведь в строки перегружен оператор ==

только newRoute ["langdir"] object

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, BogdanMart, Вы писали:

H>>>>Строка

H>>>>Я не знаю что там происходило, но изменение на второй способ сделало код работоспособным.

Z>>>Хм... точно. Одинаковые строки могут выдавать по ReferenceEquals как true так и false. Неожиданно, хотя механизм вполне понятен, компилятор строки интернирует, а рантайм, естественно, нет.
BM>>

Но ведь в строки перегружен оператор ==

Z>только newRoute ["langdir"] object

Блин, пищально... может специально для строк какой то хак встроить в немерлу...

Не зряв джаве вообще нет перегрузки оператора стравнивания, чтобы небыло таких нюансов.

З.ы. могли бы в самом дотнете сделать оператор для (object*strig) и (string*object)...

Здравствуйте, VladD2, Вы писали:

_FR>>Ага, понятно. Неужели так редко требуется переопределять == что "никому это не требовалось"?

VD>Да не так уж часто. К тому же как верно заметил Хардкейс оператор ведь пишется в пару строк. Вот всем и было наплевать.

ОК, на мой взгляд по-умолчанию операторы генерироваться должны (опять же, как раз для того что бы явно это запретить нужно иметиь основание, которое в обычной жизни не так-то просто придумать). К тому же по-умолчанию этот макрос может генерить операторы в случае только если они явно не определены.

Кстати, а IEquatable<> макрос добавляет?

_FR>>Неужели это из-за ПМ просто сравнение стало не нужно?
VD>ПМ тут в общем-то не причем.

Почему? Ну да не мне судить, в боевых условиях ПМ применять не приходилось

_FR>>Или в проверках на null, например, литеру "null" компилятор типизтрует как System.Object и сравнивает ссылки?
VD>Если оператор не определен, то да. Иначе вызывается оператор (как в шарпе). Хотя может быть как раз было бы удобнее при этом применять ссылочную эквивалентность. Я что-то не могу придумать осмысленного случая сравнения с null.

Поиск "== null" в папке Nemerle среди *.n даёт не мало результатов

Здравствуйте, _FRED_, Вы писали:

_FR>Кстати, а IEquatable<> макрос добавляет?

Нет. В компиляторе когда-то был блокирующий баг, уже не помню, поправили мы или нет.

Здравствуйте, hardcase, Вы писали:

_FR>>Кстати, а IEquatable<> макрос добавляет?

H>Нет. В компиляторе когда-то был блокирующий баг, уже не помню, поправили мы или нет.

Что за баг? В чем суть?

Здравствуйте, _FRED_, Вы писали:

_FR>ОК, на мой взгляд по-умолчанию операторы генерироваться должны (опять же, как раз для того что бы явно это запретить нужно иметиь основание, которое в обычной жизни не так-то просто придумать). К тому же по-умолчанию этот макрос может генерить операторы в случае только если они явно не определены.

+1

_FR>Кстати, а IEquatable<> макрос добавляет?

Нет. К тому же этот макрос реализует object-версию.

VD>>ПМ тут в общем-то не причем.

_FR>Почему?

Более разумным будет вопрос "Почему, причем?". ПМ не предоставляет эквивалентности объектов. Он позволяет проверить структуру объекта.

_FR>Ну да не мне судить, в боевых условиях ПМ применять не приходилось

Согласен с

. Очень советую познакомиться с ПМ по ближе.

_FR>>>Или в проверках на null, например, литеру "null" компилятор типизтрует как System.Object и сравнивает ссылки?
VD>>Если оператор не определен, то да. Иначе вызывается оператор (как в шарпе). Хотя может быть как раз было бы удобнее при этом применять ссылочную эквивалентность. Я что-то не могу придумать осмысленного случая сравнения с null.

_FR>Поиск "== null" в папке Nemerle среди *.n даёт не мало результатов

И что?

Здравствуйте, VladD2, Вы писали:

_FR>>Кстати, а IEquatable<> макрос добавляет?
VD>Нет. К тому же этот макрос реализует object-версию.

Но, справедлливости ради, в F# тоже на реализацию операторов … не сделали в общем :о)) Может быть тоже не сочли важным, редиски. Но МС если и не быстро, но планомерно исправляется в этом плане :о)

VD>>>ПМ тут в общем-то не причем.
_FR>>Почему?
VD>Более разумным будет вопрос "Почему, причем?". ПМ не предоставляет эквивалентности объектов. Он позволяет проверить структуру объекта.

Ах вот как. Мне казалось что это лишь одна из фич и ПМ в том числе может сравнивать нечно с паттернами по принципу сравнения.

_FR>>Ну да не мне судить, в боевых условиях ПМ применять не приходилось

VD>Согласен с

. Очень советую познакомиться с ПМ по ближе.

Пока только по стаьтьям/книжкам :о)) Ещё ни один язык не возбудил на столько, что бы начать использовать. В F# мне не нравится синтаксис, а в Немерле не соблюдение гудпрактик дотнета: вот в сравнении объектов, в использовании не закрытых, хоть и неизменяемых, но полей, имён в нижнем регистре в публичных членах и прочие такие вот мелочи. Так что пока только принюхиваемся :о)

Здравствуйте, VladD2, Вы писали:

VD>Что за баг? В чем суть?

Суть в том, что раньше компилятор не позволял делать вот это:

[Record]
class Foo : IEquatable[Foo]
{
  x : int;
  
  public override Equals(other : object) : bool
  {
    | other is Foo => this.x == other.x
    | _ => false
  }

  public Equals(other : Foo) : bool implements IEquatable[Foo].Equals // вот тут он ругался на неоднозначность
  {
    | null => false
    | _ => this.x == other.x
  }
  
  public override GetHashCode() : int
  {
    x.GetHashCode()
  }
}

Здравствуйте, hardcase, Вы писали:

H>Суть в том, что раньше компилятор не позволял делать вот это:
H> public Equals(other : Foo) : bool implements IEquatable[Foo].Equals // вот тут он ругался на неоднозначность

Ну, это я вроде исправил.

Здравствуйте, _FRED_, Вы писали:

_FR>Но, справедлливости ради, в F# тоже на реализацию операторов … не сделали в общем :о)) Может быть тоже не сочли важным, редиски. Но МС если и не быстро, но планомерно исправляется в этом плане :о)

А как в F# его сделать? В нем нет макросов. Мы же ведь просто говорим об одном из стандартных макросов.

Отличие Nemerle от F# как раз и заключается в том, что в Nemerle подобные вещи можно реализовать макросом. И если даже нужного макроса нет в стандартной библиотеки, или (как в данном случае) макрос не удовлетворяет потребностям, то всегда можно написать свой макрос который сделает все что надо именно тебе.

Ты ведь не ругаешь C# или F# за то, что в стандартной библиотеке нет тех или иных функций или что имеющиеся функции не делают все что тебе надо?

_FR>Пока только по стаьтьям/книжкам :о)) Ещё ни один язык не возбудил на столько, что бы начать использовать. В F# мне не нравится синтаксис, а в Немерле не соблюдение гудпрактик дотнета: вот в сравнении объектов, в использовании не закрытых, хоть и неизменяемых, но полей, имён в нижнем регистре в публичных членах и прочие такие вот мелочи. Так что пока только принюхиваемся :о)

Это все отмазки. Уверяю тебя, что просто качественно знакомство с ПМ и АлгТД сделает тебя лучше как программиста на каких бы языках ты не работал.

Здравствуйте, VladD2, Вы писали:

_FR>>Но, справедлливости ради, в F# тоже на реализацию операторов … не сделали в общем :о)) Может быть тоже не сочли важным, редиски. Но МС если и не быстро, но планомерно исправляется в этом плане :о)
VD>А как в F# его сделать? В нем нет макросов. Мы же ведь просто говорим об одном из стандартных макросов.

Я о том, что имеющиеся там (захардкоженые в компиляторе) рекорды и юнионы так же не реализуют операторов сравнения.

VD>Отличие Nemerle от F# как раз и заключается в том, что в Nemerle подобные вещи можно реализовать макросом. И если даже нужного макроса нет в стандартной библиотеки, или (как в данном случае) макрос не удовлетворяет потребностям, то всегда можно написать свой макрос который сделает все что надо именно тебе.
VD>Ты ведь не ругаешь C# или F# за то, что в стандартной библиотеке нет тех или иных функций или что имеющиеся функции не делают все что тебе надо?

Ещё как ругаю. Там нету ну очень многого. И язык, и библиотеку и много чего ещё. Я, когда мне чего-то не хватает, чего должно быть и не быть этому нет никаких оснований кроме как непродуманность/лень/прочая невынужденная причина становлюсь просто невменяем

Ну или начинаю недоумевать, что одно и то же

_FR>>Пока только по стаьтьям/книжкам :о)) Ещё ни один язык не возбудил на столько, что бы начать использовать. В F# мне не нравится синтаксис, а в Немерле не соблюдение гудпрактик дотнета: вот в сравнении объектов, в использовании не закрытых, хоть и неизменяемых, но полей, имён в нижнем регистре в публичных членах и прочие такие вот мелочи. Так что пока только принюхиваемся :о)

VD>Это все отмазки.

Конечно это отмазки, но они не менее и не более необоснованы чем ваши по теме отступления от общепринятых для дотнет норм. Я не вижу ни одной причины, по которым "ПМ и АлгТД" былибы несовместимы (технически) с отсутствие public-полей (и F# это может подтвердить), а менять одну поделку (C#) в котором нет блекджека и клоунов на другую, в котором свои критичные на мой взгляд косяки, мне не интересно.

VD>Уверяю тебя, что просто качественно знакомство с ПМ и АлгТД сделает тебя лучше как программиста на каких бы языках ты не работал.

Не сомневаюсь. Только вот когда очень приспичит я возьму F# потому что он для меня будет более предсказуемым. Потому что обладай я умениями создавать компиляторы, мне было бы стыдно делать компилятор, который создаёт и использует публичные поля (это конечно же частности, но в целом низменность моих запросов надеюсь понятна). Будет очень жаль, что не будет таких полезных макросов, но я смогу это пережить

Здравствуйте, _FRED_, Вы писали:

_FR>Не сомневаюсь. Только вот когда очень приспичит я возьму F# потому что он для меня будет более предсказуемым. Потому что обладай я умениями создавать компиляторы, мне было бы стыдно делать компилятор, который создаёт и использует публичные поля (это конечно же частности, но в целом низменность моих запросов надеюсь понятна). Будет очень жаль, что не будет таких полезных макросов, но я смогу это пережить

я извиняюсь,...

по мне ГЛАВНАЯ прелесть немерле в том что можно сделать ПОЛЕЗНЫЕ макросы САМОМУ. вот этим он лучше шарпа.
можно действительно сделать автоматическое добавление оператора ==
можно сделать макрос, чтобы ПОЛЯ в вариантах оборачивались В СВОЙСТВА
можно сделать чтобы все nullable — параметры автоматически проверялись на NotNull
...

т.е. большую часть проблем можно решить самостоятельно без вмешательства в компилятор по мере надобности
хотя эта тема 1000 раз обсуждалась

Здравствуйте, _FRED_, Вы писали:

_FR>Ещё как ругаю. Там нету ну очень многого. И язык, и библиотеку и много чего ещё. Я, когда мне чего-то не хватает, чего должно быть и не быть этому нет никаких оснований кроме как непродуманность/лень/прочая невынужденная причина становлюсь просто невменяем

Ну или начинаю недоумевать, что одно и то же

ОК, уломал речистый. Если создашь измененную реализацию макроса добавляющую операторы == и !=, создашь тесты, проконишь их и пришлешь патчь, внесу твои изменения в стандартную библиотеку и твое чувство прекрасного будет удовлетворено.

Задача не сложна. Как раз для знакомства с макрами.

_FR>Конечно это отмазки, но они не менее и не более необоснованы чем ваши по теме отступления от общепринятых для дотнет норм. Я не вижу ни одной причины, по которым "ПМ и АлгТД" былибы несовместимы (технически) с отсутствие public-полей (и F# это может подтвердить), а менять одну поделку (C#) в котором нет блекджека и клоунов на другую, в котором свои критичные на мой взгляд косяки, мне не интересно.

А они совместимы. Просто есть некоторые традиции и вне мира дотнета. Так что если ты захочешь, то можешь именовать поля как тебе нравится.

_FR>Не сомневаюсь. Только вот когда очень приспичит я возьму F# потому что он для меня будет более предсказуемым.

Ну, дык возьми. За чем дело встало то? Про предсказуемость ты (мягко говоря) заблуждаешься, но в процессе освоения ты это как раз и поймешь.

Здравствуйте, VladD2, Вы писали:
VD>ОК, уломал речистый. Если создашь измененную реализацию макроса добавляющую операторы == и !=, создашь тесты, проконишь их и пришлешь патчь, внесу твои изменения в стандартную библиотеку и твое чувство прекрасного будет удовлетворено.

Главное чтобы оно могло и не генерировать оператор... все таки есть случаи когда equals определяется, но сравнивать все ровно по ссылке надо часто.

Здравствуйте, BogdanMart, Вы писали:

BM>Главное чтобы оно могло и не генерировать оператор... все таки есть случаи когда equals определяется, но сравнивать все ровно по ссылке надо часто.

Кода нужно сравнение по ссылке, то нужно просто привести один из объектов к object или воспользоваться object.ReferenceEquals.

И, если честно, я не помню таких случаев.

Вот что действительно надо сделать, так это не определять операторов, если они уже определены вручную. Иначе макрос поломает работу кода. За одно это будет лазейкой позволяющей изменить поведение операторов.

	От:	para
	Дата:	28.02.11 20:25
	Оценка:

	От:	Аноним
	Дата:	01.03.11 05:39
	Оценка:

	От:	Ziaw
	Дата:	01.03.11 06:02
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	01.03.11 06:43
Оценка:

От:	VladD2	www.nemerle.org
Дата:	01.03.11 06:48
Оценка:

От:	hardcase	http://nemerle.org
Дата:	01.03.11 08:59
Оценка:

От:	_FRED_	@ViIvanov
Дата:	03.03.11 09:45
Оценка: