Re: как IDE решает, какую часть проэкта перепарсивать ?
От: hardcase Пират http://nemerle.org
Дата: 19.04.11 09:04
Оценка: +1
Здравствуйте, Jack128, Вы писали:

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


Вообще создавать глобально видимые классы (имя которых может ввести программист) в макросах уровня выражения не есть хороший подход.
/* иЗвиНите зА неРовнЫй поЧерК */
как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 08:56
Оценка:
допустим есть макрос, создающий тип:


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 принудительно перепарсить весь проэкт/солюшен
Re: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 08:57
Оценка:
Здравствуйте, 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 принудительно перепарсить весь проэкт/солюшен
Re[2]: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 09:15
Оценка:
Здравствуйте, hardcase, Вы писали:

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


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


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


а методы?? или свойства??? чем классы хуже?
Re[3]: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 09:17
Оценка:
Здравствуйте, Jack128, Вы писали:

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


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


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


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


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



собственно задача стоит простая: генерить ViewModel'ы для ASP.NET MVC. Имя им нужно чтобы потом из вьюхи можно было к типизированно к совйствам ViewModel обращаться.
Re[3]: как IDE решает, какую часть проэкта перепарсивать ?
От: hardcase Пират http://nemerle.org
Дата: 19.04.11 09:19
Оценка:
Здравствуйте, Jack128, Вы писали:

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


Тем что классы (TypeBuilder-ы) создаются задолго до этапа WithTypedMembers после которого типизируются тела методов (и раскрываются макросы уровня выражений).
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: как IDE решает, какую часть проэкта перепарсивать ?
От: hardcase Пират http://nemerle.org
Дата: 19.04.11 09:23
Оценка:
Здравствуйте, Jack128, Вы писали:

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


Вот тут она уже сделана.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 09:31
Оценка:
Здравствуйте, hardcase, Вы писали:

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


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


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


и?? свойства я так понимаю создаются тоже ДО того как типизируются методы ?
Re[5]: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 09:32
Оценка:
Здравствуйте, hardcase, Вы писали:

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


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


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


ну да, что то подобное я хочу повторить. Кстати, тут макросом как раз создается доступный по имени тип -)
Re[6]: как IDE решает, какую часть проэкта перепарсивать ?
От: hardcase Пират http://nemerle.org
Дата: 19.04.11 09:57
Оценка:
Здравствуйте, Jack128, Вы писали:

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


Доступ по имени происходит совсем из другой сборки — той, в которую компилируются страницы.
/* иЗвиНите зА неРовнЫй поЧерК */
Re: как IDE решает, какую часть проэкта перепарсивать ?
От: hardcase Пират http://nemerle.org
Дата: 19.04.11 09:59
Оценка:
Здравствуйте, Jack128, Вы писали:

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


А ты уверен что метод WriteLine2 в том классе появился?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[7]: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 11:02
Оценка:
Здравствуйте, hardcase, Вы писали:

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


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


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


дык какая разница то?? в ран тайм и при доступе из той же самой сборки работает, мя интересует чтоб IDE нормально работала, не выдовала лишних ошибок, когда надо — перевызывала макрос и тд..
Re[2]: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 11:02
Оценка:
Здравствуйте, hardcase, Вы писали:

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


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


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


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

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

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

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

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

наверно в таком случае повторно тип с измененным именем метода не будет генериться. ТОгда возникает вопрос, как делать правильно? Вариант с "оставить как есть, просто периодически ребилдить солюшен" конечно не интересен -)
Re[4]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.11 16:25
Оценка:
Здравствуйте, Jack128, Вы писали:

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


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

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

И вообще, общий подход для генерации типов таков. Их лучше генерировать из макро-атрибутов. Из макросов уровня выражения это тоже можно делать, но там есть масса сложностей. Так что лучше этого не делать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: как IDE решает, какую часть проэкта перепарсивать ?
От: Jack128  
Дата: 19.04.11 17:43
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>НРельсы Хардкейс уже упомянул.

нрельсы используют генерацию типа из выражения.

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


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

VD>И вообще, общий подход для генерации типов таков. Их лучше генерировать из макро-атрибутов. Из макросов уровня выражения это тоже можно делать, но там есть масса сложностей. Так что лучше этого не делать.
Re[6]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.11 18:13
Оценка:
Здравствуйте, 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-приложениях. Код для их поддержки можно генерировать теми же макросами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.11 23:42
Оценка:
Здравствуйте, Jack128, Вы писали:

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


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

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

Если же ты из одного метода ждешь, что другой создаст тип, то это может не случиться, так как порядок их типизации не определен. Даже не гарантируется, что второй метод вообще будет стипизирован во время работы IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.11 23:47
Оценка:
Здравствуйте, Jack128, Вы писали:

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


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

Кроме того типизация одного метода может происходить по много раз (после каждого изменения). И если ты не учитываешь это, то твой код, при работе под IDE, может выполняться многократно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: как IDE решает, какую часть проэкта перепарсивать ?
От: Ziaw Россия  
Дата: 20.04.11 02:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>НРельсы Хардкейс уже упомянул.

J>>нрельсы используют генерацию типа из выражения.

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


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

Конкретно по этому ты даже не объяснил почему он неверный и чем его можно заменить. Упомянул только то, что IDE на это не рассчитано. Так это архитектурный косяк IDE, а не моего решения. С точки зрения языка оно вполне рабочее. IDE при правке конечно подсвечивает красным что попало, но я привык, просто делаешь билд после редактирования и все в норме.
Re[8]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.04.11 02:44
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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

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


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

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

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


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

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


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

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

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

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

Что до рассказа о причинах проблем, то это тема не малого размера. Как-нибудь я попробую ее осветить. Но сейчас у меня банально нет ни времени на это.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: как IDE решает, какую часть проэкта перепарсивать ?
От: Ziaw Россия  
Дата: 20.04.11 03:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


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


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

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


В IDE.

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


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


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

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


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


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

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


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

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


Примерно представляю, но с удовольствием послушаю.
Re[10]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.04.11 15:42
Оценка:
Здравствуйте, 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>Примерно представляю, но с удовольствием послушаю.


ОК
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: как IDE решает, какую часть проэкта перепарсивать ?
От: Ziaw Россия  
Дата: 20.04.11 16:54
Оценка:
Здравствуйте, 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>Косяком дизайна макросов является попытка использовать что-то сгенерированное при компиляции одного метода в другом. Нужно просто понять, что тела методов могут компилироваться в разном порядке неограниченное количество раз (от нуля до бесконечности).


Вообще генерация типов востребована, без нее грустно будет.
Re[12]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.04.11 18:59
Оценка:
Здравствуйте, 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>Вообще генерация типов востребована, без нее грустно будет.


Я двадцатый раз повторяю. Сама генерация возможна. Но надо рассчитывать на недерминизм. А лучше просто искать другое решение. Еще раз повторюсь. Доступ к телу метода не закрыт из макро-атрибутов. Для описания модели лучше исползовать макро-атрибут. А уже из него можно и прочесть тело метода выцепив из него описание модели.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: как IDE решает, какую часть проэкта перепарсивать ?
От: Ziaw Россия  
Дата: 21.04.11 02:07
Оценка:
Здравствуйте, 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 раза? Метод ведь будет перекомпилирован несколько раз, сколько раз при этом будет вызван макрос?
Re[14]: как IDE решает, какую часть проэкта перепарсивать ?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.04.11 15:36
Оценка:
Здравствуйте, 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 и не производить сложных расчетов и генерации тел членов, а только ограничиться генерацией интерфейса (типов) который может быть использован в других методах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.