Здравствуйте, Codealot, Вы писали:
S>> Нет. Но там куча методов генерится.
C>То есть, без partial methods прекрасно можно обойтись?
Не прекрасно. Нужно вводить абстрактность. А это проблемы с инлайнингом.
и солнце б утром не вставало, когда бы не было меня
S>> Ну единственное решение это абстрактный класс.
C>Думаю, можно и другие найти. Опять же, чем плох абстрактный класс?
Тем что виртуальные методы плохи для инлайнинга и избавления от виртуальности VMT S>> По сути это аналог шаблонов С++, но с интеллисенсе и статической типизацией.
C>И с очень ограниченной областью применения.
Поясни в чем ограниченность? Написать свой Source Generator не можешь?
Распространяй компоненты в исходниках.
Опять же если тебе не нужны partial methods используй абстрактные в чем проблема. Больше инструментов это хорошо!
Ну и вообще надо смотреть на эволюцию SG. Сейчас практически partial methods не нужны если они уже прописаны в SG и парсер их видит.
Но бывает, что SG не хватает данных и нужны методы заглушки для интеллисенса и статической типизации.
Но опять методы можно формировать, даже если и нет данных. Обычные заглушки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Тем что виртуальные методы плохи для инлайнинга и избавления от виртуальности VMT
Экономия на спичках. В случае тех же винформ, у них уже наворочено столько уровней абстракции, что эффект от "экономии" в инициализаторе не разглядеть даже в микроскоп.
S> Поясни в чем ограниченность?
В том, что кроме генераторов, других применений у этих методов нет. В отличии от шаблонов.
S> Больше инструментов это хорошо!
Если задачу можно было решить универсальными средствами, а вместо них сделали средства для одной узко заданной задачи — это совсем не хорошо.
Здравствуйте, Codealot, Вы писали:
S>> Тем что виртуальные методы плохи для инлайнинга и избавления от виртуальности VMT
C>Экономия на спичках. В случае тех же винформ, у них уже наворочено столько уровней абстракции, что эффект от "экономии" в инициализаторе не разглядеть даже в микроскоп.
Там все упирается в Paint, по сравнению с ним лишняя косвенность копейки. S>> Поясни в чем ограниченность?
C>В том, что кроме генераторов, других применений у этих методов нет. В отличии от шаблонов.
Шаблон это и есть генератор текста. Как раз С++ щеголяли ими по сравнению с дженериками.
Просто по шаблону текст генерится во время компиляции, а для SG во время проектирования и можешь посмотреть реальный код! S>> Больше инструментов это хорошо!
C>Если задачу можно было решить универсальными средствами, а вместо них сделали средства для одной узко заданной задачи — это совсем не хорошо.
Я с тебя хренею. Вот те кто занимается SG это хорошо. А тем кто не занимается тем похрену.
И это задача совсем не узкая! Расширяются инструменты.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Там все упирается в Paint, по сравнению с ним лишняя косвенность копейки.
Можно и так сказать. В любом случае, так сильно волноваться из-за абстрактных методов в кодогенераторе — экономия на спичках.
S>Шаблон это и есть генератор текста. Как раз С++ щеголяли ими по сравнению с дженериками.
Вовсе нет, в C++ все намного сложнее.
S> Я с тебя хренею. Вот те кто занимается SG это хорошо. А тем кто не занимается тем похрену. S>И это задача совсем не узкая! Расширяются инструменты.
Просто ты никак не поймешь. Я не спрашиваю "как эту фичу можно приспособить". Я спрашиваю "почему именно так, а не иначе".
Здравствуйте, Codealot, Вы писали:
C>Просто ты никак не поймешь. Я не спрашиваю "как эту фичу можно приспособить". Я спрашиваю "почему именно так, а не иначе".
Ну вот ту разрабатываешь свой класс. Тебе нужно применить к нему какую то рутину используя кучу генераторов https://github.com/amis92/csharp-source-generators
Для римера PropertyChanged.SourceGenerator
А там нужен какой то метод помеченный для генерации. И тебе надо сначала создать абстрактный класс, на основании которого сгенерируется новый класс.
Еще раз в самом начале SG не так хорошо генерировал и подхватывались сгенеренные файлы.
Поэтому partial methods нужны прежде всего, что бы не ждать генерацию.
Немерлисты критикуют SG что макросы лучше https://rsdn.org/article/nemerle/NemerleStingFormating.xml
Здравствуйте, Serginio1, Вы писали:
S>Еще раз в самом начале SG не так хорошо генерировал и подхватывались сгенеренные файлы. S>Поэтому partial methods нужны прежде всего, что бы не ждать генерацию.
Что мешает создать абстрактный метод и реализовать его в сгенеренном коде?
Здравствуйте, Codealot, Вы писали:
S>>Еще раз в самом начале SG не так хорошо генерировал и подхватывались сгенеренные файлы. S>>Поэтому partial methods нужны прежде всего, что бы не ждать генерацию.
C>Что мешает создать абстрактный метод и реализовать его в сгенеренном коде?
Зачем городить лишний класс? Тебе бы все усложнить. НЕ ХОЧУ! Мне как раз partial methods нравятся.
Но опять же сейчас надобность в них не актуальна. SG значительно оптимизировали.
Вот так как нельзя SG модифицировать существующий код override нужен. Но проще использовать существующие методы с генерацией новых.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Зачем городить лишний класс? Тебе бы все усложнить. НЕ ХОЧУ! Мне как раз partial methods нравятся.
Это у тебя уже религиозное. Классы практически ничего не стоят, пытаться их экономить — странная идея. А новая фича в языке — это как раз очень дорого.
S>>Зачем городить лишний класс? Тебе бы все усложнить. НЕ ХОЧУ! Мне как раз partial methods нравятся.
C>Это у тебя уже религиозное. Классы практически ничего не стоят, пытаться их экономить — странная идея. А новая фича в языке — это как раз очень дорого.
Это у тебя религиозное. На самом деле partial methods это уже анахронизмы. Проще уж интерфейс использовать, а не абстрактные классы.
Как я тебе показывал примеры, прямо в описании метода ты можешь использовать сгенеренные свойства, методы итд.
Не нужно никаких partial. Просто уже SG должен существовать.
Ничего дорого нет. А вот лишние действия с двумя классами точно.
Изначально был partial method только void, без ref параметров. Нужен был для T4.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Codealot, Вы писали:
RD>>Ну а зачем заводить лишний уровень абстракции, если можно без него обойтись?
C>Пц. А это ничего, что ради этого бзика пришлось заводить целую новую фичу языка, которая вероятно будет нужна 0.0001% рарзработчиков?
Эта фича появилась в те времена, когда почти 100% UI делалось мышом, итд. Почти каждая ваканся была про WinForms, WPF
Вообще, фича крайне удобна для любой кодогенерации
Здравствуйте, Serginio1, Вы писали:
S> Не совсем. Иногда сложно читать код в разных файлах. Так для удобства чтения небольшого класса видеть все определения partial очень удобны.
Здравствуйте, Codealot, Вы писали:
P>>Вообще, фича крайне удобна для любой кодогенерации
C>Точно так же можно было использовать virtual.
Неудобно — это плохо работает с несколькими файлами, больше 2х — сиди и думай, что от чего наследуется, сущности плодятся и всегда нужна реализация, хоть какая нибудь.
Здравствуйте, Codealot, Вы писали:
S>> Не совсем. Иногда сложно читать код в разных файлах. Так для удобства чтения небольшого класса видеть все определения partial очень удобны.
C>Они у тебя и так будут в разных файлах.
Реализация будет в разных файлах, а объявление partial в основном.
и солнце б утром не вставало, когда бы не было меня
