Сделать как в Slay the Spire не сложно, если потратить некоторое время на пристальное разглядывание КАК ИМЕННО сделано в этой игре, разбить наблюдаемый функционал на отдельные блоки (декомпозиция), их реализация уже будет сильно проще. Например, поводить мышкой неспеша влево-вправо по руке, отметить, в какие моменты фокус переключается с одной карты на другую. Отметить, насколько именно карта вылезает из руки при фокусе, можно засечь время анимации (запись экрана, подсчёт кадров), можно даже примерно определить easing function, используемую при каждой конкретной анимации.
Если тебя на работе уважают, ценят и даже - нихрена себе! - хвалят, то выгореть гораздо сложнее, чем когда исподтишка травят, постоянно давят собственными дедлайнами, грозя лишением премий, а любую полезную самовольную инициативность полностью игнорируют (как максимум считая её за должное).
Я как-то мечтал о подобном, но юнити еще тогда не знал, и хотел на WPF. Ведь в игре много интерфейсов! Такая классная технология и так жаль, что не кроссплатформенная.
Ну, с одной стороны, вывод казалось бы очевидный, а с другой - без конкретных данных по "просадке" производительности это мало что полезного показывает. Да, много строчек в табличек, но что если они все особо ни на что не влияют?
Да что тут доказывать, все сильно проще. Берём, копируем вставляем текст задачи Эйнштейна боту. Бот её незамедлительно решает (конечно же). Берём абсолютно то же описание, но заменяем немца на русского. Всё, бот сломался. Пытается и думать, и спекулировать, и сразу ответ говорить, но он ни разу даже не угадал. Сразу видно, что да, думать он не умеет, причем, как это очевидно, задача изменена минимально.
Мне кажется, не должно быть сложно придумать способ, работающий без Reflection.Emit.
IDE-шка ведь имеет представление о нашем коде без какой-либо компиляции, прямо в процессе написания кода. Значит, у неё в памяти уже есть модельки, представляющие собой описание юзеровых типов и их членов. Осталось только прикрутить генерацию именно этих самых моделек (вынеся их в public api) в output инструмента "source" generators.
А тел методов можно и через делегаты реализовывать.
Исходная задача: иметь динамически изменяющуюся (от работы разработчика с кодом проекта) инфраструктуру из генерируемых типов и членов этих типов, а также помощь разработчику в виде подсветки IntelliSense. Это если я правильно понимаю полноту всей задачи, которую призван решить инструмент Source Generators.
Здесь следует обратить внимание на то, что нигде в задаче прямо не сказано, что требуется генерировать именно исходный код в виде текста. Да и какой в этом может быть смысл, если подумать? Нажать F12 и посмотреть реализацию какого-нибудь автосгенерированного метода или всего типа? Но для этого подойдёт и обычный встроенный в IDE-шку декомпилятор.
Из чего следует, что генерация сперва корректного кода, и только затем его последующая интерпретация инструментариями Source Generators во временные недосборки и их частичное подключение к среде разработки - процесс весьма неоптимальный. Мы с лёгкостью могли бы генерировать сразу типы, члены типов и инструкции для тел методов этих типов.
Если приводить аналогию, то это как если бы для обращения к какому-то классу-сервису, который ожидает от нас определенную DTO с данными, сперва генерировали бы текстовый JSON этой модели, а затем десериализовывали бы её в требуемую DTO-шку.
Поэтому и возникает резонный вопрос, а зачем нам эти танцы с генерацией текста, когда логичнее (и правильнее, и оптимальнее) было бы генерировать сразу нужные структуры для решения поставленной задачи.
Интересно, а есть генераторы, которые бы позволили генерировать .NET типы с методами "для удобства работы разработчика и т.п. IntelliSense", но без костыля в виде Source, т.е. шарпового кода? Строготипизированные, так сказать, генераторы сразу готовых типов (классов, структур, интерфейсов и т.д.) вместо текста-кода, который потом компилируется во всё то же самое?
Сделать как в Slay the Spire не сложно, если потратить некоторое время на пристальное разглядывание КАК ИМЕННО сделано в этой игре, разбить наблюдаемый функционал на отдельные блоки (декомпозиция), их реализация уже будет сильно проще. Например, поводить мышкой неспеша влево-вправо по руке, отметить, в какие моменты фокус переключается с одной карты на другую. Отметить, насколько именно карта вылезает из руки при фокусе, можно засечь время анимации (запись экрана, подсчёт кадров), можно даже примерно определить easing function, используемую при каждой конкретной анимации.
Столько воды и эпитетов... но ни слова конкретики. Чем он лучше то?
Можно отсекать людей с рейтингом меньше X.
Почему лимит сразу убьёт частные приложения? У каждого юзера вводится личный лимит, и он физически не сможет больше 2-3х запросов в секунду посылать.
Unnecessary tag detected.
Если тебя на работе уважают, ценят и даже - нихрена себе! - хвалят, то выгореть гораздо сложнее, чем когда исподтишка травят, постоянно давят собственными дедлайнами, грозя лишением премий, а любую полезную самовольную инициативность полностью игнорируют (как максимум считая её за должное).
тут компилятор, к счастью, умеет так:
Интересно, что они этим экономят.
А это не тоже ли самое? Только еще и с машиной времени.
Я как-то мечтал о подобном, но юнити еще тогда не знал, и хотел на WPF. Ведь в игре много интерфейсов! Такая классная технология и так жаль, что не кроссплатформенная.
Ну, с одной стороны, вывод казалось бы очевидный, а с другой - без конкретных данных по "просадке" производительности это мало что полезного показывает. Да, много строчек в табличек, но что если они все особо ни на что не влияют?
Для обоснования совмещения используйте
Distinct. Его тупо нет в query синтаксе.Да что тут доказывать, все сильно проще. Берём, копируем вставляем текст задачи Эйнштейна боту. Бот её незамедлительно решает (конечно же). Берём абсолютно то же описание, но заменяем немца на русского. Всё, бот сломался. Пытается и думать, и спекулировать, и сразу ответ говорить, но он ни разу даже не угадал. Сразу видно, что да, думать он не умеет, причем, как это очевидно, задача изменена минимально.
Мне кажется, не должно быть сложно придумать способ, работающий без Reflection.Emit.
IDE-шка ведь имеет представление о нашем коде без какой-либо компиляции, прямо в процессе написания кода. Значит, у неё в памяти уже есть модельки, представляющие собой описание юзеровых типов и их членов. Осталось только прикрутить генерацию именно этих самых моделек (вынеся их в public api) в output инструмента "source" generators.
А тел методов можно и через делегаты реализовывать.
Ну смотрите.
Исходная задача: иметь динамически изменяющуюся (от работы разработчика с кодом проекта) инфраструктуру из генерируемых типов и членов этих типов, а также помощь разработчику в виде подсветки IntelliSense. Это если я правильно понимаю полноту всей задачи, которую призван решить инструмент Source Generators.
Здесь следует обратить внимание на то, что нигде в задаче прямо не сказано, что требуется генерировать именно исходный код в виде текста. Да и какой в этом может быть смысл, если подумать? Нажать F12 и посмотреть реализацию какого-нибудь автосгенерированного метода или всего типа? Но для этого подойдёт и обычный встроенный в IDE-шку декомпилятор.
Из чего следует, что генерация сперва корректного кода, и только затем его последующая интерпретация инструментариями Source Generators во временные недосборки и их частичное подключение к среде разработки - процесс весьма неоптимальный. Мы с лёгкостью могли бы генерировать сразу типы, члены типов и инструкции для тел методов этих типов.
Если приводить аналогию, то это как если бы для обращения к какому-то классу-сервису, который ожидает от нас определенную DTO с данными, сперва генерировали бы текстовый JSON этой модели, а затем десериализовывали бы её в требуемую DTO-шку.
Поэтому и возникает резонный вопрос, а зачем нам эти танцы с генерацией текста, когда логичнее (и правильнее, и оптимальнее) было бы генерировать сразу нужные структуры для решения поставленной задачи.
Интересно, а есть генераторы, которые бы позволили генерировать .NET типы с методами "для удобства работы разработчика и т.п. IntelliSense", но без костыля в виде Source, т.е. шарпового кода? Строготипизированные, так сказать, генераторы сразу готовых типов (классов, структур, интерфейсов и т.д.) вместо текста-кода, который потом компилируется во всё то же самое?
тинькофф например
Да, вы правы, а я ошибся.
Но всё же WPF незаслуженно непопулярен.
Если есть аллергия на XAML, то всю его функциональность можно написать на C# (собственно, так оно и происходит при "компиляции" XAML).