I
Запись будет?
Size: a a a
2021 August 20
AN
В этот раз нет. В следущий может быть
2021 August 21
VS
Бери MigLayout -- и будет норм
ПФ
Так и делаем, но он тоже совсем не простой.
2021 August 23
Ⓢ
Ⓢ
Не обсуждали тут ещё?
DA
Интересная статья. В защиту Kotlin:
1) Java код из Kotlin правда часто приводит к NPE, но для сравнения [JS и TypeScript], [ObjectiveC и Swift] имеют похожие проблемы, и там сложнее использовать interop.
Плюс анализ Intellij IDEA помогает расставлять Nullable/NotNull аннотации в Java коде.
2) Функция '''@Synchronized suspend fun''' мне кажется плохим сочетанием. Хорошо бы в IDEA добавить такое как Warning.
Также в корутинах для синхронизации есть Channel-ы (и функции select, actor и т.д. из библиотеки kotlinx.coroutines).
3) Согласен что getter-ы могут иногда плохо влиять на производительность. Но если нужна хорошая производительность, то нужно её тестировать и замерять деградацию. Getter-ы легко поймать профилировщиком. Ну и избитая фраза - преждевременная оптимизация может быть вредной.
4) Различные способы объявления функций и лямбды дают нам много полезного. Да, надо к этому привыкнуть. Тут помагают явные типы, которые можно указывать, чтобы не ловить подобных проблем.
Но вообще статья классная. Почитать полезно.
1) Java код из Kotlin правда часто приводит к NPE, но для сравнения [JS и TypeScript], [ObjectiveC и Swift] имеют похожие проблемы, и там сложнее использовать interop.
Плюс анализ Intellij IDEA помогает расставлять Nullable/NotNull аннотации в Java коде.
2) Функция '''@Synchronized suspend fun''' мне кажется плохим сочетанием. Хорошо бы в IDEA добавить такое как Warning.
Также в корутинах для синхронизации есть Channel-ы (и функции select, actor и т.д. из библиотеки kotlinx.coroutines).
3) Согласен что getter-ы могут иногда плохо влиять на производительность. Но если нужна хорошая производительность, то нужно её тестировать и замерять деградацию. Getter-ы легко поймать профилировщиком. Ну и избитая фраза - преждевременная оптимизация может быть вредной.
4) Различные способы объявления функций и лямбды дают нам много полезного. Да, надо к этому привыкнуть. Тут помагают явные типы, которые можно указывать, чтобы не ловить подобных проблем.
Но вообще статья классная. Почитать полезно.
AN
Ну тут в целом все старое. И название misleading. Это не подводные камни котлин, а подводные камни смешанных проектов с Java/
AN
По второму пункту - просто ужасное сочетание
AN
По третьему пункту пруф можно про производительность? Не знаю как в андроиде, но в JVM это точно не верно. Нет там никакого влияния на производительность
АГ
Про андроид тоже удивлен, не слышал про такое
AN
Я посмотрел, там в статье не про это, а про то, что под виртуальным полем может быть сложная логика, которая долго работает. Не сталкивался с такой проблемой
DA
По третьему пункту я имею ввиду тот пример, который автор привёл в оригинальной статье. Когда getReference() класса
FirebaseDatabase делает сложную логику внутри себя.
Согласен что в целом с пустыми getter-ами проблем и не будет.
FirebaseDatabase делает сложную логику внутри себя.
Согласен что в целом с пустыми getter-ами проблем и не будет.
АГ
А ну так можно и в обычной функции себе в ногу выстрелить)
Но согласен, что с геттером это более неявно
Не удачный пример с функцией
Но согласен, что с геттером это более неявно
Не удачный пример с функцией
DA
Да, тут именно неявность getMethod может выстрелить.
Но честно говоря тут наверное виноваты авторы билиотеки FirebaseDatabase.
Но честно говоря тут наверное виноваты авторы билиотеки FirebaseDatabase.
АГ
Firestore этот вообще очень стремная штука
АГ
Там столько подводных камней
AN
Ну это опять же вопрос стыка с java. Если пишешь на котлин, тот тут проблема не возникает
АГ
Кстати насчет Котлина