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

VD>>В чистом ООП оно имеет смысл, так как упрощает равитие системы, при наличии паттерн-матчинга оно попросту бессмысленно.
А>А главное отжирает по три строке в каждом классе. Я к тому, что в том примере C# и Nemerle сравнивались нечестно, за счет чего и получилась, столь впечатляющая разница в объеме кода в строках. В килобайтах, кстати не так много, не в 5 раз, а в 3.

Ох уж мне эти приверженцы единственно правильных решений.

Отжирается конечно не по три строки. В приличном ОО-обществе принято каждый класс помещать в тдельный файл, а значит для каждого из них дублируется просторанство имен, using-и и прочая дрибедень. Здесь svn://rsdn.ru/RSharp находятся исходники R# который я создал до знакомства с Nemerle. Уверя, что если бы я писал подобный код сейчас и на Nemerle, то он был бы не в 3 или 5 раз меньше, а раз в 10.

VD>>2. Это очень примитивный случай. В нем паттерн-матчинг действительно не так сложно эмулировать на операторах is/as. Но с разрастанием кода станет очевидным, что эмуляция хуже оригинала. Как я говорил в статье, паттерн-матчинг поддерживеет сложные вложенные паттерны, что значительно увеличивает наши возможности. Например, если нам понадобиться распознать некий паттерн в коде (ну скажем упростить мат.выражения), то с паттерн-матчингом прийдется добавить всего пару строк кода, а в императивном коду это уже красиво не выразить. Прийдется лепить кучи if-ов.
А>Ну и где такой пример, который бы с одной стороны имел достаточную сложность для показа превосходства Nemerle, а с другой не являлся бы, например, исходниками компилятора Nemerle.

Понимаю, что мышление человека инерно. По этому предлагаю начать с малого. Давай расширим оба примера поддержкой фунций с 3 и 5 параметрами. Причем на этот раз ты продемонстриуешь свое решение первым.

Вторая здачка будет интереснее. Произвольная трансформация выражений. Берем исходное выражение применяем к нему некоторую функцию в параметах которой задем условия трасформации и получаем на выходе трансформированное (оптимизированное выражение). Для простоты, в качестве теста, будем использовать следующую оптимизацию — если выражение преставляет из себя "<любое выражение> * 1", то заменяем его на "<любое выражение>". Причем подразумевается, что это всего лишь один из возможных вариантов замены. Другими словами вызвав код вида:

expr = expr.Convert(<условия преобразования>);

мы должны получить преобразованное выражение.
Например:
До трансформации

Expression '1.23 + max(1, 2) * 1' = 3.23

После трансформации

Expression '1.23 + max(1, 2)' = 3.23

Задача понятна?
Теперь ход что называется за тобой. Ты представляешь свое решение, а затем я демонструю свое. Кстити, свое я уже написал .

VD>>Ну, и надо заметить, что кода все равно значительно больше чем на Nemerle, хотя и не так много как в чисто ОО-решении.
А>В этом и мысль.

В чем? В том, что ты потерял все приемущество ООП, но все равно не достиг такой же ясности и простоты кода?

А> Конечно превосходство Nemerle очевидно при сравнении 250 строк кода на С# и 50 строк кода на Nemerle, однако если аналогичный код на С# легко умещается в 80 строк, преимущество Nemerle испаряется.

Знаешь, многие были бы счасливы иметь 50 строк вместо 80, но на практике предпочитают 250, так как пользоваться инструментами вроде Nemerle они не умеют или боятся, а используя ООЯ прибегают к классическим паттернам проектирования приводящим именно к 250-строчному коду. И я их понимаю (правда, понимаю только в выборе паттернов, но не инструмента и парадигмы).

VD>>К тому же в нем ради "укомпакчивания" кода бвли допущены разные вольности вроде наличия Value у всех выражений хотя только оно нужно только у литералов.
А>Этого нет, Value только у Literal'ов.

Ой. Сори. Это я невнимательно смотрел код. Ну, да когда ты попыташся добавить поддеркжу метода с 3 и т.п. параметрами ты увидишь, что косяки поползут сами собой. А уж пример с оптимизацией, надесь, приведет к полному прозрению.