Source generators provide a mechanism through which source code can be generated at compile time and added to the compilation.
The additional source can be based on the content of the compilation, enabling some meta-programming scenarios.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sinix, Вы писали:
S>>Неа. Привет fody/postsharp, только с человеческим синтаксисом.
IT>Ты уверен, что Post? Если это всё будет доступно во время компиляции, то это уже не пост, а compile time. https://habrahabr.ru/post/312048/ https://github.com/Fody/PropertyChanged
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, IT, Вы писали:
S>>Неа. Привет fody/postsharp, только с человеческим синтаксисом. IT>Ты уверен, что Post? Если это всё будет доступно во время компиляции, то это уже не пост, а compile time.
Я про то, что replace/origin + codegen — это конкурент не макросам, а fody/postsharp. Расширения синтаксиса в обозримом будущем не будет.
Я бы сказал, не будет вообще. Эпоха шарп == энтерпрайз + квалификация практически всё, остался мейнстрим в полный рост. Большинство новых кастомеров — фронтэнд, мобильный геймдев и немножко облако. Почитай requests в рослине. Там 99% предложений — "я язык не изучал и не собираюсь, совместимость меня не волнует, поэтому сделайте, как мне удобно".
Ну и смысл при таком раскладе вводить возможность расширять синтаксис?
Здравствуйте, Sinix, Вы писали:
S>Я про то, что replace/origin + codegen — это конкурент не макросам, а fody/postsharp. Расширения синтаксиса в обозримом будущем не будет.
Очевидно, что речь не о текстовых макросах. Макросы этим и занимаются, что внедряются в compilation pipeline, и нагло переписывают код.
Даже без расширения синтаксиса — это уже будет очень хорошо.
S>Я бы сказал, не будет вообще. Эпоха шарп == энтерпрайз + квалификация практически всё, остался мейнстрим в полный рост. Большинство новых кастомеров — фронтэнд, мобильный геймдев и немножко облако. Почитай requests в рослине. Там 99% предложений — "я язык не изучал и не собираюсь, совместимость меня не волнует, поэтому сделайте, как мне удобно". S>Ну и смысл при таком раскладе вводить возможность расширять синтаксис?
Та пусть сначала это сделают.
Смотрел наискось, но вот это не очень понравилось:
1.
To add members to an existing class, the generated source will define a partial class. In C# this means the original class definition must be defined as partial.
С таким подходом можно всем классам сделать implicit partial и не мучаться уже (вот тока представьте, что аналайзер переписывает атрибут CheckNotNull какой-нибудь на аргументе — расползутся же partial повсюду). Имхо, если расширять язык/компилятор то дать ему уже возможность не страдать этими костылями, и оставить partial где им традиционное место. Ну а replace можно и на модификатор типа повесить, мол я собрался менять тип, пустите!
2.
To support scenarios where multiple generators may replace the same method, it will be necessary to determine an order for the chain of replacements. One possibility is to use the order of the assemblies containing the generators in the Compilation. Another possibility is to require the ambiguous replace members to have explicit [Order(...)] attributes that indicate the relative order.
Ну... т.е. мысли у них есть, что что-то пока не так, и несростается коза с бояном.
Я вообще слабо понял зачем original нужен. Аналайзер переписал метод. Тело сериализовали в GeneratedSources. Ну и хватит. А так — специальная конструкция которая подходит только для pre/post actions. Я понимаю, что это сильно упростит написание как раз врапперов, но можно и не усложнять компилятор сразу же. Были б примитивы. UPD: Впрочем по ссылке в топике есть пример генератора на кошках (json-serializer), так что наработки уже есть.
3. Не совсем понятно — переписанный код так же будет переписываться другими аналайзерами? Вроде подразумевается, но мутненько.
I>Source generators provide a mechanism through which source code can be generated at compile time and added to the compilation.
I>The additional source can be based on the content of the compilation, enabling some meta-programming scenarios.
Воооот! Вот такие вещи надо в языке прокачивать, а не эти ваши дефолтные реализации методов интерфейса и прочий сахарок для неосиливших хотя бы "банду четырёх".
Здравствуйте, ifle, Вы писали:
I>Source generators provide a mechanism through which source code can be generated at compile time and added to the compilation.
эээ... а можно какое-нибудь внятное отличие от T4?
Здравствуйте, Kolesiki, Вы писали:
K>эээ... а можно какое-нибудь внятное отличие от T4?
Т4 работает с текстами, а для анализа исходников нужно либо их самостоятельно парсить, либо лезть к сервисам студии. У сабжа же и на входе и на выходе AST.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
I>Source generators provide a mechanism through which source code can be generated at compile time and added to the compilation.
I>The additional source can be based on the content of the compilation, enabling some meta-programming scenarios.
Здравствуйте, anton_t, Вы писали:
_>Наконец Annotation Processor-ы из Java скопировали:
Одно только неясно — что именно то скопировали? Предлагаемый механизм на атрибуты никак не завязан. Самые интересные реврайтеры — как раз реагируют на тело метода.
Здравствуйте, Kolesiki, Вы писали:
K>эээ... а можно какое-нибудь внятное отличие от T4?
T4 — та ещё кака, которую авторам влом допиливать до production-ready: начиная с некоторого, причём не сильно большого, размера темплейт-оператора T4 умирает, приходится бить темплейт на куски. Как понимаете, для компилятора больших проектов такой подход неприменим (помнится, в Delphi 1 нельзя было делать юнит длиннее ~3200 строк, которые за счёт полуавтоматической генерации набегали довольно быстро — и это было реально неудобно, дробить юнит на части).
Здравствуйте, Mr.Delphist, Вы писали:
MD>T4 — та ещё кака, которую авторам влом допиливать до production-ready: начиная с некоторого, причём не сильно большого, размера темплейт-оператора T4 умирает, приходится бить темплейт на куски.
А подробонее можно? Сколько пользую T4 ни разу не замеал ничего подобного.
Если нам не помогут, то мы тоже никого не пощадим.
I>Source generators provide a mechanism through which source code can be generated at compile time and added to the compilation.
I>The additional source can be based on the content of the compilation, enabling some meta-programming scenarios.
Здравствуйте, IT, Вы писали:
IT>А подробонее можно? Сколько пользую T4 ни разу не замеал ничего подобного.
В одном из legacy-проектов в C#-исходниках был XML, точнее, заготовка будущего XML, который T4-модифицировался исходя из каких-то критериев. Постепенно Заказчик добавлял требований, XML соответственно удлинялся. В один прекрасный момент пришёл Пятачок и спросил "ой, а что это так бумкнуло". Откатились на стабильную версию — всё ОК. На последних изменениях — падает T4-преобразователь. Прошерстили десять раз шаблон — всё валидно и корректно. Тут один из коллег спросил "а что если разрезать XML пополам". Разрезали, действительно каждая половина XML генерится без проблем. Склеиваем обратно — бум. Путём дихотомии примерно нашли предел. Когда XML опять вырос и кусков вынужденно стало три, T4 был послан в сад, и его место занял XSLT.
Точный пример дать не смогу — увы, проект закрыт, доступа к репке больше нет.
Здравствуйте, Mr.Delphist, Вы писали:
MD>В одном из legacy-проектов в C#-исходниках был XML, точнее, заготовка будущего XML, который T4-модифицировался исходя из каких-то критериев. Постепенно Заказчик добавлял требований, XML соответственно удлинялся. В один прекрасный момент пришёл Пятачок и спросил "ой, а что это так бумкнуло". Откатились на стабильную версию — всё ОК. На последних изменениях — падает T4-преобразователь. Прошерстили десять раз шаблон — всё валидно и корректно. Тут один из коллег спросил "а что если разрезать XML пополам". Разрезали, действительно каждая половина XML генерится без проблем. Склеиваем обратно — бум
Скорее всего проблемы с адресным пространством. Его в студии и так постоянно в обрез, а вы своим большим XML его совсем дожрали. А xslt, небось, внешним ехе-шничком был.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Скорее всего проблемы с адресным пространством. Его в студии и так постоянно в обрез, а вы своим большим XML его совсем дожрали. А xslt, небось, внешним ехе-шничком был.
Я бы понял, если б там DOM-модель строилась, тогда да — даже мегабайт среднестатистического xml выедает память как не в себя. Но тут по сути всё процессилось как plain text — и вдруг такой казус
Здравствуйте, Mr.Delphist, Вы писали:
MD>Я бы понял, если б там DOM-модель строилась, тогда да — даже мегабайт среднестатистического xml выедает память как не в себя. Но тут по сути всё процессилось как plain text — и вдруг такой казус
Там весь выхлоп набирается в StringBuilder, а тот хранит все единым куском. Если адресное пространство сильно фрагментировано это может быть проблемой.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Если нам не помогут, то мы тоже никого не пощадим.
