Да, это стоило бы обыграть директивами предпроцессора, но последствия такого решения минимальны. Всегда можно просто поменять на стандартные классы, и весь код будет снова компилироваться и работать.
На сколько я помню, ИИ для игры в Го обучался с целью выиграть у самого себя, придумывая с каждой итерацией все более изощренные стратегии.
Модель для Copilot же обучалась с целью как можно точнее предсказать следующий участок кода среднестатистического проекта с открытым исходным кодом на основе предыдущего. От такого подхода я бы не стал ожидать каких-то принципиально новых решений просто потому, что у модели нет такой задачи.
Пока не изобретут способ оценить степень соответствия кода требованиям и заказчиков, и разработчиков, и потребителей, нейросеть не станет генерировать код, который будет находить новые способы эти требования закрыть.
Для чего в запросе удаления дублирующихся строк сначала разбивать массив на последовательность строк, затем снова собирать это в массив?
Массив можно сразу передать в ANY, а чтобы Postgres не считал подзапрос полседовательностью массивов, в которой нужно найти ctid, результат подзапроса можно кастануть:
DELETE FROM
hier
WHERE
ctid = ANY((
SELECT
(array_agg(ctid))[2:]
FROM
hier
GROUP BY
pid, ord
HAVING
count(*) > 1
)::tid[]);
С принципом разделения виджетов на виджеты я согласен, но только с организационной точки зрения. Аргументация про производительность не верна:
константы лишний раз не перерисовываются в отличие от функции
Виджеты-константы перерисовываются так же, как и обычные виджеты. При каждом их использовании создаются такие же узлы и в element tree, и в render tree . Их плюс в том, что они не пересоздаются каждый раз при перестроении дерева виджетов. Чтобы виджет лишний раз не перерисовывался, используют RepaintBoundary.
Функции могут возвращать константный виджет, который не будет пересоздаваться при каждом ее вызове. Достаточно использовать ключевое слово const перед вызовом const конструктора. Это стоит делать и в build методах.
При замене функции или метода на константный виджет, мы меняем вызов функции или метода на вызов build метода константного виджета фреймворком. Результат этого метода может быть возвращать как константный, так и обычный объект => сама по себе замена функции виджетом не повлияет на производительность в лучшую сторону.
Да, это стоило бы обыграть директивами предпроцессора, но последствия такого решения минимальны. Всегда можно просто поменять на стандартные классы, и весь код будет снова компилироваться и работать.
На сколько я помню, ИИ для игры в Го обучался с целью выиграть у самого себя, придумывая с каждой итерацией все более изощренные стратегии.
Модель для Copilot же обучалась с целью как можно точнее предсказать следующий участок кода среднестатистического проекта с открытым исходным кодом на основе предыдущего. От такого подхода я бы не стал ожидать каких-то принципиально новых решений просто потому, что у модели нет такой задачи.
Пока не изобретут способ оценить степень соответствия кода требованиям и заказчиков, и разработчиков, и потребителей, нейросеть не станет генерировать код, который будет находить новые способы эти требования закрыть.
Для чего в запросе удаления дублирующихся строк сначала разбивать массив на последовательность строк, затем снова собирать это в массив?
Массив можно сразу передать в
ANY, а чтобы Postgres не считал подзапрос полседовательностью массивов, в которой нужно найтиctid, результат подзапроса можно кастануть:С принципом разделения виджетов на виджеты я согласен, но только с организационной точки зрения. Аргументация про производительность не верна:
Виджеты-константы перерисовываются так же, как и обычные виджеты. При каждом их использовании создаются такие же узлы и в element tree, и в render tree . Их плюс в том, что они не пересоздаются каждый раз при перестроении дерева виджетов. Чтобы виджет лишний раз не перерисовывался, используют
RepaintBoundary.Функции могут возвращать константный виджет, который не будет пересоздаваться при каждом ее вызове. Достаточно использовать ключевое слово
constперед вызовомconstконструктора. Это стоит делать и вbuildметодах.При замене функции или метода на константный виджет, мы меняем вызов функции или метода на вызов
buildметода константного виджета фреймворком. Результат этого метода может быть возвращать как константный, так и обычный объект => сама по себе замена функции виджетом не повлияет на производительность в лучшую сторону.