IO
когда тебе не нужно разбирать конструкции, типа: вот индекс этот индекс идет по размеру масива, к элементу масива с индексом мы применяем такое действие.
я понимаю разницу, но просто на уровне компиляции билдскрипта это никак не различить
Size: a a a
2020 May 17
IO
предлагается же искуственно запретить императивный код в build.gradle?
AN
предлагается же искуственно запретить императивный код в build.gradle?
не надо ничего запрещать. Просто почистить
BP
я понимаю разницу, но просто на уровне компиляции билдскрипта это никак не различить
да по факту нет, мы же в jvm мире
IO
не надо ничего запрещать. Просто почистить
и так везде рекомендуют убирать императив
IO
но в реальных проектах уходит некоторое время на вынос всего такого в buildSrc
IO
кстати, тут панаму упоминали. тоже слюнки текут из-за нормальной работы с off-heap'ом
AN
и так везде рекомендуют убирать императив
Ну тут скорее даже не про императив речь, а про какую-то логику с состояниями, которую сложно читать и воспринимать
AN
кстати, тут панаму упоминали. тоже слюнки текут из-за нормальной работы с off-heap'ом
off-heap завезли в 14. Я пока не тыкал правда. Опять же висит issue в kmath
AN
но в реальных проектах уходит некоторое время на вынос всего такого в buildSrc
да, но оно того стоит. Я вообще в плагины вынес
AN
off-heap завезли в 14. Я пока не тыкал правда. Опять же висит issue в kmath
IO
Ну тут скорее даже не про императив речь, а про какую-то логику с состояниями, которую сложно читать и воспринимать
ну прям стейт довольно редко встречается
AN
ну прям стейт довольно редко встречается
Проблема с градлом в том, что у него очень сложная (и императивная!) внутренняя модель и порядок инициализации. Поэтому любые вставки билд логики начинают выглядеть крайней громоздко, при том, что билд файл должен читаться максимально просто и быстро
AN
Просто добавление таски с небольшим императивным кодом - ОК, но вот изменение настроек конфигураций помимо того, что доступно простыми конфигурациями - это уже тяжело
AM
ну а как определить, императив это или не императив?
Никак, конечно, пока билдконфиг пишется на грувях или котлине.
AN
Никак, конечно, пока билдконфиг пишется на грувях или котлине.
Полностью декларативно - это только в maven и там от этого гибкость сильно страдает
АО
Ну как... Там не билдскрипт, а билдконфиг, этим всё сказано, впринципе
AM
Полностью декларативно - это только в maven и там от этого гибкость сильно страдает
В мавене, если я правильно понял, не так легко кастомную логику в билд написать, как в гредле с buildSrc. Ну и это тоже не предел мечтаний. Но оформленных мыслей, как это могло бы выглядеть, нет.
AN
В мавене, если я правильно понял, не так легко кастомную логику в билд написать, как в гредле с buildSrc. Ну и это тоже не предел мечтаний. Но оформленных мыслей, как это могло бы выглядеть, нет.
В мавене для того, чтобы что-то вставить в билд надо деплоить плагин. И это большая проблема. Градл в принципе более или менее держит баланс между юзабельностью и декларативностью, но да, у него серьезная проблема с кривизной модели. Проблема, понятно, историческая. Им надо держать обратную совместимость.
BV
У мавена кстати есть скриптовый конфиг