λ
штош
F[_] ?Size: a a a
2021 March 22
λ
а как в ютраке заквотить
λ
а 'F[_]'
AD
implicitly[Sugak[F]]
2021 March 23
IP
Ещё такой странный вопрос появился. Я помню что в c++ есть препроцессор/макросы. Директивами ifdef можно было управлять какие куски кода/фичи включать в результирующую сборку, а какие нет, задавая некоторые константы компилятору/билд тулу. Для java я нагуглил manifold есть. Быть может у кого-то есть опыт использования подобных вещей или есть что-то лучше именно для scala
IP
Так manifold получается не для java а для Idea...
ΛВ
можно такое на макросах сделать в теории
ΛВ
зависит от задачи
Oℕ
Ещё такой странный вопрос появился. Я помню что в c++ есть препроцессор/макросы. Директивами ifdef можно было управлять какие куски кода/фичи включать в результирующую сборку, а какие нет, задавая некоторые константы компилятору/билд тулу. Для java я нагуглил manifold есть. Быть может у кого-то есть опыт использования подобных вещей или есть что-то лучше именно для scala
Плагины компилятора могут читать флаги компилятора специальные
EK
Ещё такой странный вопрос появился. Я помню что в c++ есть препроцессор/макросы. Директивами ifdef можно было управлять какие куски кода/фичи включать в результирующую сборку, а какие нет, задавая некоторые константы компилятору/билд тулу. Для java я нагуглил manifold есть. Быть может у кого-то есть опыт использования подобных вещей или есть что-то лучше именно для scala
Опенсорс авторы сталкиваются с этой проблемой, когда нужно поддерживать проект для разных версий скалы и скалы-жс.
Это решается созданием отдельных build directories и трюками с наследованием:
Можно попробовать делать так же. В билд конфигурации нужно будет задать нужные build directories для конкретного типа релиза.
Это решается созданием отдельных build directories и трюками с наследованием:
MyService extends MyServiceVersionSpecific.Можно попробовать делать так же. В билд конфигурации нужно будет задать нужные build directories для конкретного типа релиза.
EK
Но лучше, наверное, не делать так для бизнес логики, а просто попробовать правильно структурировать модули
IP
Есть более простой выход, попробовать закрыть определённые роуты feature флагами. Это может не совсем решить проблему исключения неиспользуемого кода из результирующего билда, но уже что-то. И тут два выхода - на уровне какого-то файла с object со всеми флагами играться и менять в этом файле в зависимости от того что надо или более правильный - это выностить на уровень билд тула. Но на уровне билд тула вопрос (возможно глупый): есть ли в sbt возможность пробрасывать какие-то вещи в код, т.е. в зависимости от конфига формировать тело того самого object со всеми feature флагами?
ΛВ
Есть более простой выход, попробовать закрыть определённые роуты feature флагами. Это может не совсем решить проблему исключения неиспользуемого кода из результирующего билда, но уже что-то. И тут два выхода - на уровне какого-то файла с object со всеми флагами играться и менять в этом файле в зависимости от того что надо или более правильный - это выностить на уровень билд тула. Но на уровне билд тула вопрос (возможно глупый): есть ли в sbt возможность пробрасывать какие-то вещи в код, т.е. в зависимости от конфига формировать тело того самого object со всеми feature флагами?
sbt-buildinfo плагин умеет
ΛВ
но он заточен под конкретную инфу, не расширяется
ΛВ
с другой стороны можно скопировать код из него
ΛВ
хотя там вроде можно произвольную мапку закинуть, например с фича-флагами
IP
с другой стороны можно скопировать код из него
Ну да, спасибо за наводку
Oℕ
ну sbt-buildinfo это просто кодогенерация
ΛВ
хотя опять же, проще сделать конфиг где-то в условном vault со всеми флагами и подтягивать его потом из приложения
Oℕ
кодогенерацию, конечно можно сделать любую