Опять кодогенерация, шаблонизаторы vs AST

[metaclass]

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

И поначалу это гораздо понятнее, чем кодогенератор с использованием AST целевого языка и претти-принтингом оного AST в исходники.
Но есть одно НО.
Результат без подсветки синтаксиса и автоформатирования к поддержке практически непригоден. Исходник представляет собой смесь C# кода, который выполняется и C# кода который генерируется, с разделителями вида <#,<#=,<#+ и #>. Без заточенного под это дело редактора после определенного уровня сложности кодогенератора в этом понять ничего невозможно.

Например, я, упившись крепким чаем, в припадке безумия таки реализовал свою старую идею - генерацию из простой модели иммутабельных сущностей и методов сохранения и загрузки оных сущностей в простой XML, где полям-значениям соответствуют атрибуты, полям-объектам - элементы, полям-спискам(List<>) - элементы с вложенными списками. Т.е. вариант XML, в котором это дело наиболее читабельно глазами. Если не боитесь пауков - можете глянуть на этот мрак.
По мере расширения этого кодогенератора (простые сущности-записи -> сущности с полями-списками -> поддержка enum -> поддержка полей-вложенных объектов -> поддержка memo-полей (строки в которых длинный текст с переносами)) это все понемногу превратилось в жопный ад. 10 кб текста, 300 строк, в которых даже я с трудом ориентируюсь уже.
Использовать это очень просто, расширять дальше - уже сложно.

Кроме того, во всей этой кодогенерации очень бесит необходимость постоянно расширять систему типов. Т.к. один и тот же string в целевой проге - это может быть и коротенькое имя, и текст SQL запроса и RTF-документ. А при показе поля с датой пользователю может быть необходимо использовать culture-invariant формат (например я для служебных данных и для себя пользуюсь везде только им, чтобы не вспоминать "на какой локали я сижу") а может и формат из текущей локали.
В общем, если делать классическими дотнетовскими средствами, как положено, то на каждое поле или проперть в POCO-сущности навешивается еще 5-10 атрибутов, и по всему коду расползается анализ этих атрибутов, т.е. фактически мало того, что мы расширяем систему типов дополнительными описаниями, так еще и всю их обработку делаем в рунтайме, как с какой-то динамической типизацией.



PS: Во, вспомнил еще идею, которая мне насчет T4 в голову пришла.
Частенько в C# не хватает ADT, но их можно сымитировать, сделав базовый класс и унаследовав от него все варианты ADT с нужными полями. Чтобы сделать pattern matching поверх этого, нужно написать в базовом классе метод, в который передается в качестве параметров по одному делегату на каждый вариант ADT и он анализирует текущий тип объекта, вызывая соответствующий делегат, подставляя поля варианта в качестве параметров делегату.

Руками такое писать очевидно влом. Но можно сделать на T4 мелкий шаблончик, который из описания ADT в привычном виде сгенерит все классы, конструктора, прототипы делегатов и метод для pattern matching.

Comments

[berezovsky.livejournal.com]

какэто чяем

[metaclass.livejournal.com]

Ну ложки три заварки, литр воды и 6 кубиков сахара.
Глаза в общем-то на лоб лезут :)

[berezovsky.livejournal.com]

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

[metaclass.livejournal.com]

А где покупается пуэр в черных блинах?
Хотя вообще всякие оолонги обычно пью.

Нащот кальция это чо-то да.

[wizzard]

>> один и тот же string в целевой проге - это может быть и коротенькое имя, и текст SQL запроса и RTF-документ

А если заворачивать в прокси-обьекты, которые для работы с внешними API умеют implicit operator string(RTFText text) { return text.value; }
?

[metaclass.livejournal.com]

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

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

[paranoekk.livejournal.com]

И что делать, кодогенерация тоже тупиковый путь?

[metaclass.livejournal.com]

Не, не тупиковый. Главное вовремя остановится и не уйти в дебри.

Тут по самой сути задачи безумие - в одной модели хранятся описания данных и описания маппингов этих данных на другие представления. Тут это "удобный" XML и юзерочитабельное представление, а у меня ж еще предстоит генерить схему БД, маппинги в нее, желательно GUI и что там еще, бинарную сериализацию какую-нибудь. Но это все я уже делаю на F#, с AST и прочими заморочками, т.к. C# из-за отсутствия ADT не хватает для некоторых сложных случаев.

[zelanton.livejournal.com]

Эх, я себе давно уже такой написал и много лет уже пользую. Такими жабами оброс - мама дорогая. Например не только в XML и БД серилизация, но в ini-шки (и это древовидные полиморфные структуры).

[metaclass.livejournal.com]

Во-во, обрастает жабами, натурально.

[zelanton.livejournal.com]

ребе, я потом этих жаб подрезал аккуратненько и сейчас оно прекрасно, пользуюсь с удовольствием.
Одно плохо - всё это счастье теперь на C# переписать, оно ж у меня на делфи. Но перепишу обязательно, универсальный же инструмент получился.

[zamotivator.livejournal.com]

И чем это отличается от Template Haskell?

P.S. Упс, походу я этим комментом шаблоны порву

[zamotivator.livejournal.com]

Ну или от camlp4.
Тоже самое по сути.

Выглядит пиздато, писать заебёшься.

[metaclass.livejournal.com]

Именно так.
Я, правда, camlp4 не смотрел, но подумываю, что неплохо было бы T4 на F# портировать :)

[metaclass.livejournal.com]

Ээээ, нетипизированностью?

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

[permea-kra.livejournal.com]

>>тайпчекинг там на ходу как-то делается
Как-то. Руками.

>>Кстати, для отладки промежуточный текст очень сильно удобен
-ddump-*

[norguhtar.livejournal.com]

Товарищи объясните мне, зачем все это вуду таки надо?

[metaclass.livejournal.com]

Чтобы ничего не делать, а все работало :)

[norguhtar.livejournal.com]

Непокатит. Какой профит оно дает и за счет чего?

[thedeemon.livejournal.com]

А вот спорим не будет такого момента, когда все будет работать и ребе метакласс ничего не будет делать?

[thedeemon.livejournal.com]

Это называется Model Driven Development. На Software Engineering Radio ему уже давно всякие немцы дифирамбы пели.

[norguhtar.livejournal.com]

Просто это вуду похлеще Spring Framework который я использую.

[theiced.livejournal.com]

А теперича, ребе, посмотрите на макросы в лиспе и начинайте завидовать чОрной завистью.

[metaclass.livejournal.com]

Не, не, я не представляю, как ЭТО отлаживать.

[theiced.livejournal.com]

в смысле?