А вы любите, когда ваш код вам врет?

Так уж получилось, что любой фронтенд по мере усложнения задачи и фреймворков имеет свойство скатываться в непонятное нечто. Взять к примеру мой любимый пример с javascript:

Console.log("3"+2); //5
Console.log("3"-2); //1

и перенести его на Android со сладким-сладким котлином:

operator fun String.minus(n : Int) = this.toInt() - n
    
fun main() {
   println("3" + 2) //5
   println("3" - 2) //1
}

Когда вы в последний раз видели такое в строгой но справедливой матушке Java? (на самом деле, куча ловушек и в ней, просто мы их выучили)

И вот сегодня, меня порадовали еще одним квизом. Угадайте что делает следующая строка в xml:

app:myCustomBinding="@{SystemUiHider.SInsetsHolder.top + ResourceUtils.dipToPx(context, @dimen/statement_padding_16dp)}"

Если ваш ответ: складывает между собой два числа SystemUiHider.SInsetsHolder.top и ResourceUtils.dipToPx(context, @dimen/statement_padding_16dp) и отдает их на вход кастомному байндинг-адаптеру, то поздравляю. Вы отстали от жизни, ок бумер, иди кодь на своем делфи и не лезь к клевым пацанам.

Ответ от gen-z: так как переменная SInsetsHolder имеет тип androidx.databinding.BaseObservable, то “умная” кодогенерация подпишет все выражение в скобках @{..} на изменение параметра top и будет вызывать его когда нужно. Возможно главная ошибка проектировщиков датабайндинга в том, что они попытались имитировать синтаксис простой java в xml. Когда на самом деле, нужен был свой dsl-синтаксис. Тогда бы не было недопониманий.

Ну и вывод: Конечно, сахар может ускорить процесс написания кода и сделать его fun. Но цена - это полная утеря понятия о том, что происходит в приложении на самом деле.