VD>Еще можно воспользоваться активными паттернами. Это аналогично введению своего макроса, только значительно проще.

еще момент: при первом взгляде на

Sum(a : int, b : int) : option[int]
{
   Some(b - a)
}

парсер вылетает с исключением (мой парсер, а не немерлешный)

при втором начинаешь подозревать опечатку (- вместо +)

вывод из этого тот, что *реализацию* (т.е. код Sum) надо показывать только после примера использования (т.е. после active match(y) ...)

и кстати еще один вопрос -- а что будет, если юзер напишет х,2 вместо 2,х:

active match(5)
{
  | 4 => Console.WriteLine(4);
  | Sum(x,2) => Console.WriteLine(x);
  | _ => Console.WriteLine("You will never see it");
}

VD>Еще можно воспользоваться активными паттернами. Это аналогично введению своего макроса, только значительно проще.

слово active можно было бы распологать у самого паттерна, а не у слова match:

match(5)
{
  | 4 => Console.WriteLine(4);
  | active Sum(2,x) => Console.WriteLine(x);
  | _ => Console.WriteLine("You will never see it");
}

тогда была бы возможность пользоваться как обычными паттернами, так и активными в рамках одного матчинга

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

I>Выложу, как только разберусь с DI контейнерами. Хотя, если хочешь посмотреть, можно сейчас уже сделать приватный репо.
I>Там ещё одна проблема осталась, копирование статичных данных в новую сборку.

Да мне не к спеху, все равно сейчас на рельсах пишу, в моно разве что потестить могу, если развернуть можно быстро.

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

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

Z>Да мне не к спеху, все равно сейчас на рельсах пишу, в моно разве что потестить могу, если развернуть можно быстро.

А что с NRails кстати?

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

C>А что с NRails кстати?

Да ничего. Я приостановил работу, когда понял, что проблем с интеграцией в 2008 студию будет больше чем с самим движком, а 2008 в тот момент стремительно уходила в небытие. Сейчас уже можно было бы пробовать написать интеграцию для 2010, но у меня нет задач, в которых я мог бы применить nrails. Если бы было время и задачи, я бы сейчас не стал завязываться на ASP.NET MVC, а сделал бы отдельные модули для генерации типов и маппинга, для роутинга, для генерации view. И применил бы все для NancyFx, который не требует специальных заточек студии и хостится в чем угодно.

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

Возможно система перекомпиляции на лету от ionoy, даст какую-то базу, для построения похожего по юзабилити решения, но все равно, есть куча моментов, которые на решениях от ms приходится делать через задницу. И есть куча прикладных инфраструктурных задач, которые требуют реализации и поддержки (организация скриптов и стилей, трансляция в javascript, вменяемый роутинг). Я не могу столько времени уделять на хобби.

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