ппц, а ещё на них умирает Android Lint. Предупреждения о minSdk видно только после выноса в маленький файл

🤣.

чтобы андроид линт не умирал, мы ему добавляем на CI -XmxNNNg где NNN > 6.

(но с андроидом нас отсюда попросят сейчас)

да я чем больше добавлю, тем больше своппиться будет, нуегонафиг)

йес, пришлось, конечно оперативки туда 64 гига накинуть сначала )) чтобы он GC-ится и не думал...

21 век, чо, технологии))

@noraltavir а вот и JVM IR Beta в 1.4.30 - https://youtrack.jetbrains.com/issue/KT-43592

Да, сам только что увидел. Будем переезжать. Интересно, дебаг не сломается?

Всем привет. Подскажите, пожалуйста, ваше мнение по поводу infix функций.
В Котлин код стайле говорится, что они должны использоваться только для двух объектов с одинаковой ролью. И не должно быть присваивания.
Я согласен, что использовать их везде не стоит или даже нельзя.
Однако как на счет использования в контексте (объект действие цель)?
Например:
view onCkick presenter::action
view attachText viewModel.liveData
context register broadcastReceiver
Как к таким вещам относится комьюнити и на сколько вам было бы дискомфортно прийти на проект, который использует такие инфиксы?

Я бы сказал, что их можно использовать по-разному. Но вот то, что вы предлагаете явно так себе. Не понятно, что дает в смысле читаемости

я бы сказал напоминает руби

По мне, это сокращение стандартных действий.
View.onClick(presenter::action) в обычном написании, как по мне неверно названная функция. В лучшем случае view.setOnClick(presenter::action) или view.setClickListener(presenter::action) обычная запись слушателя не подходит, т.к. ее нужно переопределить.

я переопределяю, зачем тут инфикс

А как называете?

также

inline fun View.setOnClickListener(listener: () -> Unit) = setOnClickListener { listener() }

если я правильно вас понял и вы хотите через референсы ставить слушатель

Мы на слушатели кликов дополнительно вешаем debounce, чтобы избежать двойного нажатия. И хотелось поддержать одинаково названной функцией входящие параметры ()->Unit, (v)->Unit и View.OnClickListener.

С (v)->Unit перестарался, его не поддерживаем))

В общем я понял. Действуем по код стайлу. Спасибо за мнение)
Чисто из любопытства, есть ли те, кто не против такого подхода или я единственный уникум такой?))

Да наверняка найдутся, все люди разные. Но лично меня скорее отпугивает кардинальная разница в возможностях написания в языке, как-то раз я прочел статью на лурке по поводу скалы и послушал отзывы скалистов, которые подтвердили что там можно 5-6 совершенно разными способами(стилями) написать один и тот же код, и адепты одного стиля не принимают другие, после чего решил что не очень хочется брать этот язык для разработки проекта, хрен пойми как найти нужного разраба в таком случае

А вам надо будет каким-то образом потом понимать что новопришедшие люди в команду ваш кодстайл/подход поддержат и примут, а не покрутят пальцем у виска и уйдут)