Кстати, о логерах. Я тут подумал - удобнее будет, ...
# russian
a
Кстати, о логерах. Я тут подумал - удобнее будет, если стандартный логер будет принимать лямбду https://jira.qos.ch/browse/SLF4J-504 http://mailman.qos.ch/pipermail/slf4j-dev/2020-December/005484.html https://github.com/qos-ch/slf4j/pull/253 Если у кого есть желание- поддержите, что ли 🙂 Тогда любой логер для котлина в jvm будет выглядеть проще. PS: оказывается есть https://github.com/qos-ch/slf4j/pull/252 - но там автор немного ошибся, плюс не создал ни таску в джире, ни тред в рассылке.
r
a
Мне не нравится, что это очередная обёрка, каждая из которых сново выполняет isTraceAllowed()
Лучше, если kotlin-logging будет напрямую звать метод, а не проверять ещё раз.
i
В slf4j добавили билдер стайл, и видимо это тот путь который они видят правильным. Не думаю что они будут ещё больше раздувать API. Проблемы с inline оберткой не вижу совсем
Ну и почему только trace? А debug/info?
a
Естественно, что там то же самое. Просто я не хочу писать, если это не нужно. trace это полноценный пример, остально никак не меняется.
a
Немного некропостинг, но мы ушли на log4j2, slf4j умер в развитии и автор не особо шевелится 😞
i
Slf4j это API, в первую очередь для библиотек
Чисто из интереса, а чего в log4j2 есть такого, чего не хватает в logback?
a
Да скорее не понятно когда logback/slf4j вернутся в мир живых, в это же время log4j2 делает garbage-free логирование, API с лямбдами, поддержка структурного логирования
Я вот только сейчас увидел, что они новые alpha-релизы этим летом выложили. До этого 3 года тишины