I
Я думаю, было слишком много ложных срабатываний. Поэтому если и есть, то только для внутреннего пользования.
Function..?<kotlin\.Unit Профит!Size: a a a
2021 November 26
IP
Короче, вариант для бедных. Берем binary-compatibility-validator, применяем, в *.api ищем
IP
Хотя вроде, если изначально проектировать интерфейс с мыслью о джавистах, то сразу под подозрение падает любой котлиновский функциональный тип: j.u.f.Function всяко идиоматичнее k.Function1
VS
Почему над механическими проверками должен думать я, а не компилятор/верификатор?
В идеале, конечно, он ещё и предлагать должен: вот вы тут сделали public метод в companion object. Вы к нему либо @JvmStatic добавьте, либо в internal переведите. Иначе в Java придётся делать Class.Companion.method(...)
В идеале, конечно, он ещё и предлагать должен: вот вы тут сделали public метод в companion object. Вы к нему либо @JvmStatic добавьте, либо в internal переведите. Иначе в Java придётся делать Class.Companion.method(...)
VS
Ну, режим explicitApi же изобрели?
Тут очень похожая тема, но, конечно, более мутная.
Тут очень похожая тема, но, конечно, более мутная.
АО
Чувак может быть джун, который подсмотрел, что так делают :) так что лучше перестраховаться, имхо
с#
в либе наверное стоит, но в приложении между вьюмоделью и вью может быть всё равно
АО
спорный момент, может повлечь изменение состояний не с той стороны
АО
понятно, что есть всякие ревью и прочее такое, но вопрос в том, что если у тебя StateFlow - даже с кастом работать не будет как mutable
с#
ладно, пусть. а как ты защищаешься от изменения листа?
АО
делаю обычный лист 🌚 ну или копирую, если нужно быть уверенным
с#
эммм…
АО
да, я знаю, что там мутабле будет
АО
но поэтому я и уточнил, что в лишних местах я копирую списки
с#
я сделал .toList, чтобы показать, что даже копирование не меняет мутабле
АО
IP
А issue где?