допустим есть макрос, создающий тип:

Main(): void 
{ 
    CreateModule(typeName = "MyClass", methodName = "WriteLine");
    MyClass.WriteLine("строка");
    _ = Console.ReadLine();
}

все компилируется, IDE ошибок не выдает, все отлично.

теперь подправим имя метода и его использование

Main(): void 
{ 
    CreateModule(typeName = "MyClass", methodName = "WriteLine2");
    MyClass2.WriteLine2("строка");
    _ = Console.ReadLine();
}

код компилируется, но IDE пишет, что тип метод WriteLine2- не найден. Собственно как дать hint IDE, что тип MyClass изменился ?? Или хотя бы заставить IDE принудительно перепарсить весь проэкт/солюшен

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

J>допустим есть макрос, создающий тип:


J>

J>Main(): void 
J>{ 
J>    CreateModule(typeName = "MyClass", methodName = "WriteLine");
J>    MyClass.WriteLine("строка");
J>    _ = Console.ReadLine();
J>}
J>

J>все компилируется, IDE ошибок не выдает, все отлично.

J>теперь подправим имя метода и его использование


J>

J>Main(): void 
J>{ 
J>    CreateModule(typeName = "MyClass", methodName = "WriteLine2");
J>    MyClass2.WriteLine2("строка"); // тут опечатка, естественно MyClass нужно писать
J>    _ = Console.ReadLine();
J>}
J>

J>код компилируется, но IDE пишет, что тип метод WriteLine2- не найден. Собственно как дать hint IDE, что тип MyClass изменился ?? Или хотя бы заставить IDE принудительно перепарсить весь проэкт/солюшен

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

J>код компилируется, но IDE пишет, что тип метод WriteLine2- не найден. Собственно как дать hint IDE, что тип MyClass изменился ?? Или хотя бы заставить IDE принудительно перепарсить весь проэкт/солюшен

Вообще создавать глобально видимые классы (имя которых может ввести программист) в макросах уровня выражения не есть хороший подход.

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

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

J>>код компилируется, но IDE пишет, что тип метод WriteLine2- не найден. Собственно как дать hint IDE, что тип MyClass изменился ?? Или хотя бы заставить IDE принудительно перепарсить весь проэкт/солюшен

H>Вообще создавать глобально видимые классы (имя которых может ввести программист) в макросах уровня выражения не есть хороший подход.

а методы?? или свойства??? чем классы хуже?

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

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

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

J>>>код компилируется, но IDE пишет, что тип метод WriteLine2- не найден. Собственно как дать hint IDE, что тип MyClass изменился ?? Или хотя бы заставить IDE принудительно перепарсить весь проэкт/солюшен

H>>Вообще создавать глобально видимые классы (имя которых может ввести программист) в макросах уровня выражения не есть хороший подход.

J>а методы?? или свойства??? чем классы хуже?


собственно задача стоит простая: генерить ViewModel'ы для ASP.NET MVC. Имя им нужно чтобы потом из вьюхи можно было к типизированно к совйствам ViewModel обращаться.

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

J>а методы?? или свойства??? чем классы хуже?

Тем что классы (TypeBuilder-ы) создаются задолго до этапа WithTypedMembers после которого типизируются тела методов (и раскрываются макросы уровня выражений).

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

J>собственно задача стоит простая: генерить ViewModel'ы для ASP.NET MVC. Имя им нужно чтобы потом из вьюхи можно было к типизированно к совйствам ViewModel обращаться.

Вот тут она уже сделана.

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

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

J>>а методы?? или свойства??? чем классы хуже?

H>Тем что классы (TypeBuilder-ы) создаются задолго до этапа WithTypedMembers после которого типизируются тела методов (и раскрываются макросы уровня выражений).

и?? свойства я так понимаю создаются тоже ДО того как типизируются методы ?

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

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

J>>собственно задача стоит простая: генерить ViewModel'ы для ASP.NET MVC. Имя им нужно чтобы потом из вьюхи можно было к типизированно к совйствам ViewModel обращаться.

H>Вот тут она уже сделана.

ну да, что то подобное я хочу повторить. Кстати, тут макросом как раз создается доступный по имени тип -)

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

J>ну да, что то подобное я хочу повторить. Кстати, тут макросом как раз создается доступный по имени тип -)

Доступ по имени происходит совсем из другой сборки — той, в которую компилируются страницы.

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

J>код компилируется, но IDE пишет, что тип метод WriteLine2- не найден.

А ты уверен что метод WriteLine2 в том классе появился?

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

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

J>>ну да, что то подобное я хочу повторить. Кстати, тут макросом как раз создается доступный по имени тип -)

H>Доступ по имени происходит совсем из другой сборки — той, в которую компилируются страницы.

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

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

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

J>>код компилируется, но IDE пишет, что тип метод WriteLine2- не найден.

H>А ты уверен что метод WriteLine2 в том классе появился?

хм. вопрос конечно интересный. Может и нет.

Вот смотри, сначала я написал просто

macro ViewModel(...)
{
... генерим тип
<[ () ]>
}

но так периодически возникала ошибка, что каждую декларацию типа нужно помечать модификатором partial.

тогда я стал хранить имена сгенерированных типов в Manager.UserData и соотвественно тестить when (UserData.Contains(typeName)) { ..генерим тип; UserData.Add(typeName); }

наверно в таком случае повторно тип с измененным именем метода не будет генериться. ТОгда возникает вопрос, как делать правильно? Вариант с "оставить как есть, просто периодически ребилдить солюшен" конечно не интересен -)

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

J>собственно задача стоит простая: генерить ViewModel'ы для ASP.NET MVC. Имя им нужно чтобы потом из вьюхи можно было к типизированно к совйствам ViewModel обращаться.

НРельсы Хардкейс уже упомянул. Я же дам ссылку на другой подход использованный в Nemerle.WUI.Reactive. Это прототип фрэймворка для интерактивного веба. Но там тоже используется паттерн MVVM.

Подход основан на том, что ViewModel описывается как отдельный класс на который навешивается макро-атрибует. Этот макро-атрибут генерит ява-сткрипт (что нужно для фрэймворка), но может генерить и нужный тебе код.

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

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

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

J>>собственно задача стоит простая: генерить ViewModel'ы для ASP.NET MVC. Имя им нужно чтобы потом из вьюхи можно было к типизированно к совйствам ViewModel обращаться.

VD>НРельсы Хардкейс уже упомянул.
нрельсы используют генерацию типа из выражения.

VD>Я же дам ссылку на другой подход использованный в Nemerle.WUI.Reactive. Это прототип фрэймворка для интерактивного веба. Но там тоже используется паттерн MVVM.

Используется, то используется. Но я то думал просто заюзать проверенный asp.net mvc, и с помощью N избавить от тучи рукописного кода, а не писать свой framework. Блин, теже анонимные классы, только не анонимные, а с фиксированным именем.

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

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

VD>>НРельсы Хардкейс уже упомянул.
J>нрельсы используют генерацию типа из выражения.

Я автора предупреждал, что это неверный подход. Но у него на все свое мнение.

J>Используется, то используется. Но я то думал просто заюзать проверенный asp.net mvc, и с помощью N избавить от тучи рукописного кода, а не писать свой framework. Блин, теже анонимные классы, только не анонимные, а с фиксированным именем.

Откровенно говоря asp.net mvc — это тупиковый подход. Немерл может помочь только лишь добавить к нему костыли, так чтобы не приходилось постоянно делать море повторяющейся работы. Но сама идеология у него гнилая. Как только на сайте понадобится динамика, то большую часть работы придется делать ручками да еще и на жабаскрипте.

Если же ты хочешь использовать asp.net mvc, то или бери нрельсы (их скорее всего тоже придется доводить до ума, но все же не малый объем работы уже проделан), или делай надстройку сам. Во втором случае я бы тебе посоветовал описать модель как это сделано в Nemerle.WUI.Reactive, а всю логику генерации кода реализовать в макро-атрибуте.

Если же хочешь действительно революционного решения которое сократит время разработки сложных сайтов в десятки раз, то могу предложить развитие проекта Nemerle.WUI.Reactive. Я его планировал, что его кто-то возьмет под свое крыло и разовьет в самодостаточный фрэймворк создания сайтов. Ну, а уже на нем мы бы сделали (в последствии) как сайт немерла, так и rsdn.ru.

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

В двух словах Nemerle.WUI.Reactive — это набор макросов которые позволяли бы создавать интерактивные сайты (на базе жабаскрипта) на основе модели MVVM.

Общая идеология работы с в нем планируется следующая.
1. Декларативно описываем модель представления определяющую данные отражаемые в UI. Требуемые зависимости описываются как использование свойств объекта модели представления в других свойствах и методах. Этот код пишется на Немерле.
2. Описываем представления которые выглядят как простые методы возвращающие XML (фрагменты HTML).
3. В представлении декларативно описываем связывание (биндинг) между свойствами модели представления и вложенными представлениями (например, текстовыми полями или таблицами).

При этом никаких обработчиков событий. Никакого UI-кода. Все основывается на декларативном биндинге.

Представления в этой схеме выполняют сразу две роли. С одной стороны — это средство ренеденга HTML. С другой это налог контролов в АСТ.НЭТ, так как представления могут ссылаться на другие представления или на самим себя же. Например, может быть преставление грид. Его модель — это таблица состоящая из строк и ячеек данных в строках.
На этапе компиляции по представлениям генерируется как начальный HTML, так и жабаскрипт-код автоматически обновляющий представление на клиенте при изменении модели представления (и наоборот, обновляющий модель представления при изменении представления).

В итоге получается декларативная модель построения интерактивного Web UI.

Кроме того полученное описание модели можно без проблем использовать в других UI-приложениях, например в WPF-приложениях. Код для их поддержки можно генерировать теми же макросами.

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

J>дык какая разница то?? в ран тайм и при доступе из той же самой сборки работает, мя интересует чтоб IDE нормально работала, не выдовала лишних ошибок, когда надо — перевызывала макрос и тд..

Огромная. Нет проблем с IDE. Ведь к моменту когда тебе понабобится комплит по этому типу он уже будет взять из сборки.

А вот методы в IDE перетипизируются по сто раз. Изменил метод и здравствуй новая его типизация. При этом раскрываются макросы.

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

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

J>но так периодически возникала ошибка, что каждую декларацию типа нужно помечать модификатором partial.

Это из-за того, что типизация метода содержащего ошибки производится в два прохода. Сначала "быстрая" (без формирования сообщений об ошибках), а затем второй — с формированием. Об этом во многих статьях рассказано. Побочные эффекты (коим является создание класса или даже формирования сообщения об ошибках) нужно делать только в если IsMainPath == true.

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

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

VD>>>НРельсы Хардкейс уже упомянул.
J>>нрельсы используют генерацию типа из выражения.

VD>Я автора предупреждал, что это неверный подход. Но у него на все свое мнение.

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

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

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

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

Не преувеличивай. Объяснить не получилось ни по одному пункту. Просто я забил на объяснения. Что-то лучше чем ничего.
Собственно, хуже всего то, что работа по сути брошена не доведенной до релиза. Если бы ее плотно использовали, то все само собой устаканилось бы.

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

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

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

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

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

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

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

Все кто не по годам умны могут сесть и попытаться спроектировать архитектуру IDE без косяков.
Ну, а тем кто не так крут я советую прислушиваться к советам тех кто этот путь уже прошел. И не делать архитектурных косяков в своих макросах.

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

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

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