Исходная задача: иметь динамически изменяющуюся (от работы разработчика с кодом проекта) инфраструктуру из генерируемых типов и членов этих типов, а также помощь разработчику в виде подсветки IntelliSense. Это если я правильно понимаю полноту всей задачи, которую призван решить инструмент Source Generators.
Здесь следует обратить внимание на то, что нигде в задаче прямо не сказано, что требуется генерировать именно исходный код в виде текста. Да и какой в этом может быть смысл, если подумать? Нажать F12 и посмотреть реализацию какого-нибудь автосгенерированного метода или всего типа? Но для этого подойдёт и обычный встроенный в IDE-шку декомпилятор.
Из чего следует, что генерация сперва корректного кода, и только затем его последующая интерпретация инструментариями Source Generators во временные недосборки и их частичное подключение к среде разработки - процесс весьма неоптимальный. Мы с лёгкостью могли бы генерировать сразу типы, члены типов и инструкции для тел методов этих типов.
Если приводить аналогию, то это как если бы для обращения к какому-то классу-сервису, который ожидает от нас определенную DTO с данными, сперва генерировали бы текстовый JSON этой модели, а затем десериализовывали бы её в требуемую DTO-шку.
Поэтому и возникает резонный вопрос, а зачем нам эти танцы с генерацией текста, когда логичнее (и правильнее, и оптимальнее) было бы генерировать сразу нужные структуры для решения поставленной задачи.
Интересно, а есть генераторы, которые бы позволили генерировать .NET типы с методами "для удобства работы разработчика и т.п. IntelliSense", но без костыля в виде Source, т.е. шарпового кода? Строготипизированные, так сказать, генераторы сразу готовых типов (классов, структур, интерфейсов и т.д.) вместо текста-кода, который потом компилируется во всё то же самое?
Я более того скажу - зачем ВООБЩЕ нужен этот архаичный Startup? Он же сильно нарушает очевидность своей же работы, т.к. работает без контракта.
Нет, понятно, что контракт есть, но не в файле интерфейса, а где-то в дебрях MSDN-ов. Где-то там, в обычных текстах в интернете, находятся нужные сигнатуры методов. Но к чему этот головняк, если весь его функционал полностью доступен и через обычные методы, с очевидными прямо в коде сигнатурами?
Эти UseStartup<> тянутся из древности уже не один десяток лет, а интерфейс (да хоть бы и через generic constraint) к нему так толком и не прикрутили. При этом его использую очень много людей, практически повсеместно. Зачем?
Ну логично, ведь изза какого-нибудь runtime условия переменную могут как подменить, так и нет. Вам же не нужна потенциальная runtime ошибка, когда её можно подсветить уже на этапе компиляции?)
Можно допилить, сделав необязательным соблюдение порядка вызова методов у `VideoProcessingSettings`. Всяко автору библиотеки виднее, какой порядок более правильный, чем пользователю.
Ну, есть еще другая тема - у человека яркость (как и громкость) воспринимается нелинейно, а скорее логарифмически. Поэтому, кстати, многие аудиоплееры имеют логарифмический регулятор громкости. А AIMP, например, имеет настройку, позволяющую выбирать между этими двумя режимами..
А что не так с вашим "утрированием"? nullable позволяет выбросить наконец надоевшую валидацию по всему коду, бесконечные Guard.NotNull и прочие NRE на продуктиве.
Добавляется не пара процентов, а все 100% гарантии отсутствия null/NRE при условии, что вы этот nullable, конечно же, умеете готовить.
Я просто очень много видел людей, которые вставляют восклицательный знак то тут то там, а потом кричат, что nullable — фигня полная.
Практика "never null" хороша в попытке решить вышеуказанные проблемы (когда нет альтернативы в виде nullable context), но лишает возможности использовать null как инструмент в принципе, а это уже минус. Доп. минусом сюда идёт в комплекте то, что любой рандомный разраб всегда может случайно вернуть этот null куда не следует, и всё, считай, на смарку. Только потом еще есть шанс не найти этого места.
Ну смотрите.
Исходная задача: иметь динамически изменяющуюся (от работы разработчика с кодом проекта) инфраструктуру из генерируемых типов и членов этих типов, а также помощь разработчику в виде подсветки IntelliSense. Это если я правильно понимаю полноту всей задачи, которую призван решить инструмент Source Generators.
Здесь следует обратить внимание на то, что нигде в задаче прямо не сказано, что требуется генерировать именно исходный код в виде текста. Да и какой в этом может быть смысл, если подумать? Нажать F12 и посмотреть реализацию какого-нибудь автосгенерированного метода или всего типа? Но для этого подойдёт и обычный встроенный в IDE-шку декомпилятор.
Из чего следует, что генерация сперва корректного кода, и только затем его последующая интерпретация инструментариями Source Generators во временные недосборки и их частичное подключение к среде разработки - процесс весьма неоптимальный. Мы с лёгкостью могли бы генерировать сразу типы, члены типов и инструкции для тел методов этих типов.
Если приводить аналогию, то это как если бы для обращения к какому-то классу-сервису, который ожидает от нас определенную DTO с данными, сперва генерировали бы текстовый JSON этой модели, а затем десериализовывали бы её в требуемую DTO-шку.
Поэтому и возникает резонный вопрос, а зачем нам эти танцы с генерацией текста, когда логичнее (и правильнее, и оптимальнее) было бы генерировать сразу нужные структуры для решения поставленной задачи.
Интересно, а есть генераторы, которые бы позволили генерировать .NET типы с методами "для удобства работы разработчика и т.п. IntelliSense", но без костыля в виде Source, т.е. шарпового кода? Строготипизированные, так сказать, генераторы сразу готовых типов (классов, структур, интерфейсов и т.д.) вместо текста-кода, который потом компилируется во всё то же самое?
тинькофф например
Да, вы правы, а я ошибся.
Но всё же WPF незаслуженно непопулярен.
Если есть аллергия на XAML, то всю его функциональность можно написать на C# (собственно, так оно и происходит при "компиляции" XAML).
Я более того скажу - зачем ВООБЩЕ нужен этот архаичный Startup? Он же сильно нарушает очевидность своей же работы, т.к. работает без контракта.
Нет, понятно, что контракт есть, но не в файле интерфейса, а где-то в дебрях MSDN-ов. Где-то там, в обычных текстах в интернете, находятся нужные сигнатуры методов. Но к чему этот головняк, если весь его функционал полностью доступен и через обычные методы, с очевидными прямо в коде сигнатурами?
Эти
UseStartup<>тянутся из древности уже не один десяток лет, а интерфейс (да хоть бы и через generic constraint) к нему так толком и не прикрутили. При этом его использую очень много людей, практически повсеместно. Зачем?Работает до первого резонного "зависит от чего?".
Ну логично, ведь изза какого-нибудь runtime условия переменную могут как подменить, так и нет. Вам же не нужна потенциальная runtime ошибка, когда её можно подсветить уже на этапе компиляции?)
Можно допилить, сделав необязательным соблюдение порядка вызова методов у `VideoProcessingSettings`. Всяко автору библиотеки виднее, какой порядок более правильный, чем пользователю.
Спасибо за идею с конденсатором.
А смысл их продавать и покупать-то? Что за подозрительные операции?
Это было самым ожидаемой, и тем не менее, все равно очень крутой возможностью.
Штош, давно пора! (я сам моноколёсник).
Похожу на рекламу... Плохо чтоль?
Автору 15? Обалдеть, красавчик тогда. Я в 15 сделал полноценный мультиплеер, но дальше локалхоста ничего никуда не умел выкладывать и делать.
Ну, есть еще другая тема - у человека яркость (как и громкость) воспринимается нелинейно, а скорее логарифмически. Поэтому, кстати, многие аудиоплееры имеют логарифмический регулятор громкости. А AIMP, например, имеет настройку, позволяющую выбирать между этими двумя режимами..
Ну, т.е. всё вышеуказанное в принципе лечится обычным `#nullable enable`?
А что не так с вашим "утрированием"? nullable позволяет выбросить наконец надоевшую валидацию по всему коду, бесконечные
Guard.NotNullи прочие NRE на продуктиве.Добавляется не пара процентов, а все 100% гарантии отсутствия
null/NRE при условии, что вы этот nullable, конечно же, умеете готовить.Я просто очень много видел людей, которые вставляют восклицательный знак то тут то там, а потом кричат, что nullable — фигня полная.
Практика "never null" хороша в попытке решить вышеуказанные проблемы (когда нет альтернативы в виде nullable context), но лишает возможности использовать null как инструмент в принципе, а это уже минус. Доп. минусом сюда идёт в комплекте то, что любой рандомный разраб всегда может случайно вернуть этот
nullкуда не следует, и всё, считай, на смарку. Только потом еще есть шанс не найти этого места.Вряд ли маленькие дети могут лазать по стенам на высоте 2-3х метров