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

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

Проект был экспериментальный, просто проверка концепций, в этом смысле он удался. Брошен он потому, что не я не имею возможности использовать его в продакшене, не смог перейти на 4й фреймворк и MVC 3, не смог сделать нормальную интеграцию в студию для спарка, хотя хотелось бы вообще razor. Сейчас я использую то, что смог перевести на 4й фреймворк — миграции. Веб часть пока не удалось.

Z>>Конкретно по этому ты даже не объяснил почему он неверный и чем его можно заменить.

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

Макроатрибут уровня сборки? Какой в этом смысл? Сокращенное описание класса? Это даст лишь небольшую экономию на символах. Требуется легко передавать во вьюху довольно сложные объекты из контороллера тип которых будет выведен. Если все типы в этом контейнере придется описывать явно, решение не имеет смысла, с тем же успехом можно объявить класс.

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

В IDE.

Z>>Упомянул только то, что IDE на это не рассчитано.

VD>И IDE, и сами макросы. Чтобы макра уровня выражения работала надежна она должна не содержать побочных эффектов. Иначе надо много разных факторов в голове держать. И это точно не для начинающего, коим ты был когда начал работать над своим макросом. Даже в макры Камила (автора макросистемы) глючили когда он нарушал это правило.

Значит надо признать, что nemerle просто не справляется с подобными задачами и вообще не решать ее. Макроатрибут тут ничем не поможет.

Z>>Так это архитектурный косяк IDE, а не моего решения. С точки зрения языка оно вполне рабочее. IDE при правке конечно подсвечивает красным что попало, но я привык, просто делаешь билд после редактирования и все в норме.

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

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

VD>Я ответственно заявляю, что в Н1 наличие побочных эффектов в макросах уровня выражения — это потенциальная проблема (и несомненно архитектурный косяк).

Жаль если решение будет в сторону запрета такой генерации. Анонимные типы придется хардкодить в компилятор.

VD>Что до рассказа о причинах проблем, то это тема не малого размера. Как-нибудь я попробую ее осветить. Но сейчас у меня банально нет ни времени на это.

Примерно представляю, но с удовольствием послушаю.

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

Z>Проект был экспериментальный, просто проверка концепций, в этом смысле он удался. Брошен он потому, что не я не имею возможности использовать его в продакшене, не смог перейти на 4й фреймворк и MVC 3, не смог сделать нормальную интеграцию в студию для спарка, хотя хотелось бы вообще razor. Сейчас я использую то, что смог перевести на 4й фреймворк — миграции. Веб часть пока не удалось.

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

Ну, а интеграция Разоров и т.п. — это уже вопрос расширяемости решений от МС. Если они не расширяются, то не надо их использовать.

Z>Макроатрибут уровня сборки?

Не обязательно. Подойдет любого уровня (типа, члена, например).

Z>Какой в этом смысл? Сокращенное описание класса? Это даст лишь небольшую экономию на символах.

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

Z> Требуется легко передавать во вьюху довольно сложные объекты из контороллера тип которых будет выведен. Если все типы в этом контейнере придется описывать явно, решение не имеет смысла, с тем же успехом можно объявить класс.

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

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

Z>В IDE.

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

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

Потом то что макра не работает в IDE — это уже косяк достойный того чтобы не писать так код.

IDE по другому работать физически не может. Не будешь же ты ждать полной компиляции проекта после каждого изменения кода? А вот написать макрос по другому не сложно.

VD>>И IDE, и сами макросы. Чтобы макра уровня выражения работала надежна она должна не содержать побочных эффектов. Иначе надо много разных факторов в голове держать. И это точно не для начинающего, коим ты был когда начал работать над своим макросом. Даже в макры Камила (автора макросистемы) глючили когда он нарушал это правило.

Z>Значит надо признать, что nemerle просто не справляется с подобными задачами и вообще не решать ее. Макроатрибут тут ничем не поможет.

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

Z>>>Так это архитектурный косяк IDE, а не моего решения. С точки зрения языка оно вполне рабочее. IDE при правке конечно подсвечивает красным что попало, но я привык, просто делаешь билд после редактирования и все в норме.

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

Z>Признавал и признаю, что косяк конкретно этого решения в том, что IDE с ним неверно работает. К сожалению других решений проблемы я не вижу.

Не хочешь видеть. Вон погляди на тот же PegGrammar. Макрос по сложнее твоего раз в дцать. Но работает надежно и правильно.

VD>>Я ответственно заявляю, что в Н1 наличие побочных эффектов в макросах уровня выражения — это потенциальная проблема (и несомненно архитектурный косяк).

Z>Жаль если решение будет в сторону запрета такой генерации. Анонимные типы придется хардкодить в компилятор.

Генерация типов из маросов-выражений не запрещена, но опасна и сложна. С анонимными типами в данном случае справиться можно. Они ведь анонимные, а значит локальны для каждого метода. Все что нужно сделать — это конролировать, чтобы тип не создавался повторно.

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

VD>>Что до рассказа о причинах проблем, то это тема не малого размера. Как-нибудь я попробую ее осветить. Но сейчас у меня банально нет ни времени на это.

Z>Примерно представляю, но с удовольствием послушаю.

ОК

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

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

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

VD>Ну, а интеграция Разоров и т.п. — это уже вопрос расширяемости решений от МС. Если они не расширяются, то не надо их использовать.

С разором я разберусь. А а вот запустить MVC 3 на nemerle мне не удалось, уже не знаю кто тут виноват больше, мои кривые руки, студия или интеграция немерла. Еще не очень понятно, потребуется ли писать интеграцию для nhtml, если потребуется — труба.

VD>Я тебе уже кажется рассказывал как получить огромную экономию. Но у тебя опять свое мнение и слушать ты меня не хочешь.

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

Z>> Требуется легко передавать во вьюху довольно сложные объекты из контороллера тип которых будет выведен. Если все типы в этом контейнере придется описывать явно, решение не имеет смысла, с тем же успехом можно объявить класс.

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

Это решение не призвано покрыть все сценарии, но есть куча мест, где она экономит время.

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

Казалось бы при чем тут приватные члены? Это тупо генерация DTO.

VD>То что макра написанная таким образом работает не гарантирует, что она будет работать когда проект изменится.

VD>Потом то что макра не работает в IDE — это уже косяк достойный того чтобы не писать так код.

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

Как по другому-то? Хватит уже намеков.

Z>>Значит надо признать, что nemerle просто не справляется с подобными задачами и вообще не решать ее. Макроатрибут тут ничем не поможет.

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

Не орлее и не упертее тебя.

Z>>Признавал и признаю, что косяк конкретно этого решения в том, что IDE с ним неверно работает. К сожалению других решений проблемы я не вижу.

VD>Не хочешь видеть. Вон погляди на тот же PegGrammar. Макрос по сложнее твоего раз в дцать. Но работает надежно и правильно.

Уел брат, уел. Много внешних классов генерит этот макрос?

VD>Генерация типов из маросов-выражений не запрещена, но опасна и сложна. С анонимными типами в данном случае справиться можно. Они ведь анонимные, а значит локальны для каждого метода. Все что нужно сделать — это конролировать, чтобы тип не создавался повторно.

Ну вот и решение нашлось. Стоило скандалить-то? Косяк то получается не архитектурный, а в деталях реализации.

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

Вообще генерация типов востребована, без нее грустно будет.

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

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

Я на тебя не пеняю, а констатирую факт. Теперь это ограничение снято.

VD>>Ну, а интеграция Разоров и т.п. — это уже вопрос расширяемости решений от МС. Если они не расширяются, то не надо их использовать.

Z>С разором я разберусь. А а вот запустить MVC 3 на nemerle мне не удалось, уже не знаю кто тут виноват больше, мои кривые руки, студия или интеграция немерла. Еще не очень понятно, потребуется ли писать интеграцию для nhtml, если потребуется — труба.

Кто такой nhtml?

Что до вопросов интеграции, то у можно поспрашивать у орлов из МС. Может что-то подскажут. Сформулируй вопросы и пришли мне. Я их отошлю куда надо.

VD>>Я тебе уже кажется рассказывал как получить огромную экономию. Но у тебя опять свое мнение и слушать ты меня не хочешь.

Z>Отказаться вообще от ASP.NET MVC, ага, спасибо.

Ага. Пожалуйста. ASP.NET ни в каком виде не дает значимых (заметных) средств борьбы со сложностью. Они просто идут по тупиковому пути. Красивое слово MVC у них снова превратилось в профанацию. Цепляться за это дело нет ни малейшего смысла.

С твоим знанием предмета и моим знанием макросов можно было бы давно закончить Реактивный фрэмворк и получить несравнимо более высокоуровневое решение.

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

Ты видишь такие же ошибки дизайна, как в интеграции. Тут не дизайн нужно исправлять, а твое ИМХО.

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

Z>Это решение не призвано покрыть все сценарии, но есть куча мест, где она экономит время.

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

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

Z>Казалось бы при чем тут приватные члены? Это тупо генерация DTO.

При том, что твой макрос может быть вызвать из них.

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

Z>Как по другому-то? Хватит уже намеков.

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

Z>Не орлее и не упертее тебя.

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

Z>Уел брат, уел. Много внешних классов генерит этот макрос?

Он генерирует методы. Что тоже самое в разрезе данной проблемы. Важно что это макро-атрибут. Это приводит к детерминизму.

Собственно твоя проблема могла бы быть решена точно так же. Ты мог бы навесить на представление макро-атрибут из которого тупо почесть тело метода и сделать все то что ты делаешь. Это автоматом сделало бы твой макрос правильно работающим при любых условиях (в IDE и компиляторе).

VD>>Генерация типов из маросов-выражений не запрещена, но опасна и сложна. С анонимными типами в данном случае справиться можно. Они ведь анонимные, а значит локальны для каждого метода. Все что нужно сделать — это конролировать, чтобы тип не создавался повторно.

Z>Ну вот и решение нашлось. Стоило скандалить-то? Косяк то получается не архитектурный, а в деталях реализации.

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

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

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

Z>Вообще генерация типов востребована, без нее грустно будет.

Я двадцатый раз повторяю. Сама генерация возможна. Но надо рассчитывать на недерминизм. А лучше просто искать другое решение. Еще раз повторюсь. Доступ к телу метода не закрыт из макро-атрибутов. Для описания модели лучше исползовать макро-атрибут. А уже из него можно и прочесть тело метода выцепив из него описание модели.

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

VD>Кто такой nhtml?

Гипотетический аналог cshtml и vbhtml. Разоровских вьюх.

VD>Что до вопросов интеграции, то у можно поспрашивать у орлов из МС. Может что-то подскажут. Сформулируй вопросы и пришли мне. Я их отошлю куда надо.

Ну для начала надо понять, кто выдает NotSupportedException при загрузке немерлового проекта если в него добавить гуид ProjectType ASP.NET MVC.

А вопрос короткий, что нужно реализовать для поддержки файлов разора на nemerle в IDE.

Z>>Казалось бы при чем тут приватные члены? Это тупо генерация DTO.

VD>При том, что твой макрос может быть вызвать из них.

Не может, он должен быть вызван из метода контроллера.

VD>Собственно твоя проблема могла бы быть решена точно так же. Ты мог бы навесить на представление макро-атрибут из которого тупо почесть тело метода и сделать все то что ты делаешь. Это автоматом сделало бы твой макрос правильно работающим при любых условиях (в IDE и компиляторе).

Предлагаешь такой вариант?

[GenerateViewModelClass]
public SomeAction() : ActionResult
{
  def range = Enumerable.Range(1, 10).Select(i => new (i = i));
  View(range)
}

Макрос анализирует вызовы View в теле метода и генерит нужные классы? В принципе можно, а как это поможет от генерации одного и того же класса 2 раза? Метод ведь будет перекомпилирован несколько раз, сколько раз при этом будет вызван макрос?

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

Z>Ну для начала надо понять, кто выдает NotSupportedException при загрузке немерлового проекта если в него добавить гуид ProjectType ASP.NET MVC.

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

Z>А вопрос короткий, что нужно реализовать для поддержки файлов разора на nemerle в IDE.

Это очень общий вопрос. В прочем можно попробовать задать.

Z>Предлагаешь такой вариант?

Я не то чтобы предлагаю. Я говорю о возможных путях.

Z>

Z>[GenerateViewModelClass]
Z>public SomeAction() : ActionResult
Z>{
Z>  def range = Enumerable.Range(1, 10).Select(i => new (i = i));
Z>  View(range)
Z>}
Z>

Z>Макрос анализирует вызовы View в теле метода и генерит нужные классы? В принципе можно, а как это поможет от генерации одного и того же класса 2 раза? Метод ведь будет перекомпилирован несколько раз, сколько раз при этом будет вызван макрос?

Макро-атрибут вызывается ровно один раз — при перестроении дерева типов. Если он будет вызван повторно, значит происходит перестроение дерева типов, а это, в свою очередь, означает, что старые типы уже уничтожены.

Минус тут только один. Код макроса будет затормаживать перестроение дерева типов. Так что его нужно делать как можно более шустрым. Например, анализировать, что макрос работает под управлением IDE и не производить сложных расчетов и генерации тел членов, а только ограничиться генерацией интерфейса (типов) который может быть использован в других методах.