Size: a a a

Kotlin Community

2020 March 30

VP

Vladimir Petrakovich in Kotlin Community
Quantum Harmonizer
форк или выпил, ясное дело
Отличная перспектива, именно то, что надо.
Подключаешь либу, у тебя через некоторое время всё взрывается в рантайме, и чтобы это исправить, надо срочно её форкать.
источник

RE

Roman Elizarov in Kotlin Community
Кирилл Романенко
А почему так? Или киньте в меня ссылкой, пожалуйста. Я поискал дискуссии по этому багу, но не нашёл. Мб плохо искал.
Дискусии нет, потому что это не баг, а особенности порядка инициализации. Его можно поменять так, чтобы конкретно этот код заработал, но тогда сломается какой-нибудь другой код. В общем случае нет решения которое бы всегда работало и каждый практический ЯП выбирает какой-то порядок и живет с ним и с тем кодом, который из-за него не работает. Не очень понятно какое на эту тему может быть обсуждение.
источник

КР

Кирилл Романенко in Kotlin Community
Roman Elizarov
Дискусии нет, потому что это не баг, а особенности порядка инициализации. Его можно поменять так, чтобы конкретно этот код заработал, но тогда сломается какой-нибудь другой код. В общем случае нет решения которое бы всегда работало и каждый практический ЯП выбирает какой-то порядок и живет с ним и с тем кодом, который из-за него не работает. Не очень понятно какое на эту тему может быть обсуждение.
Понятно, спасибо
источник

BP

Bogdan Panchenko in Kotlin Community
Quantum Harmonizer
очевидно, мне надо выпустить новую версию с обновлённой зависимостью
все так оперативно работают (нет)
источник

QH

Quantum Harmonizer in Kotlin Community
Bogdan Panchenko
все так оперативно работают (нет)
и чо делать? Писать свою библиотеку вместо того чтобы использовать существующую, потому что она может сломаться?
источник

BP

Bogdan Panchenko in Kotlin Community
Quantum Harmonizer
форк или выпил, ясное дело
звучит так: "хочу вечный рефакторинг"
источник

BP

Bogdan Panchenko in Kotlin Community
Quantum Harmonizer
и чо делать? Писать свою библиотеку вместо того чтобы использовать существующую, потому что она может сломаться?
нужно оценивать риски, если библиотеку не собираются забрасывать - то все ок, если там не часто меняют апи и стараются держатся совместимости - ок. Я вот либы от JB +- сарзу обновляю, даже если что-то сломалось то оно довольно быстро фиксица. (Не хочу продолжать холивар)
источник

QH

Quantum Harmonizer in Kotlin Community
Прекрасно. Оценивать риски.
И не поспоришь, действительно надо.
источник

VP

Vladimir Petrakovich in Kotlin Community
Quantum Harmonizer
и чо делать? Писать свою библиотеку вместо того чтобы использовать существующую, потому что она может сломаться?
В случае не с kotlinx.collections.immutable - перемещать её в другой пакет и не показывать наружу.
Если показывать наружу всё-таки надо - ну тогда да, остаётся только использовать так.
Только надо не забыть поставить версию зависимости как strict 🙂
источник

BP

Bogdan Panchenko in Kotlin Community
Quantum Harmonizer
Прекрасно. Оценивать риски.
И не поспоришь, действительно надо.
еще бы знать как это делать 🙃
источник

AN

Alexander Nozik in Kotlin Community
Vladimir Petrakovich
Ладно бы это SortedSet был, ну так его и добавить не проблема
источник

VP

Vladimir Petrakovich in Kotlin Community
Интересная штука, только их SortedSet почему-то java.util.SortedSet не реализует
источник

AN

Alexander Nozik in Kotlin Community
Vladimir Petrakovich
Интересная штука, только их SortedSet почему-то java.util.SortedSet не реализует
Так мультиплатформа же. Сделать так, чтобы он подставлял жавовый сет на платформе дольше, сложнее и не понятно зачем.
источник

AN

Alexander Nozik in Kotlin Community
Я не говорю, кстати, что хорошая либа, просто участвовал в обсуждении, когда оно стартовало, поэтому помню, где лежит
источник

VP

Vladimir Petrakovich in Kotlin Community
Alexander Nozik
Так мультиплатформа же. Сделать так, чтобы он подставлял жавовый сет на платформе дольше, сложнее и не понятно зачем.
Чтобы меньше проблем ловить, когда в stdlib появится
typealias SortedSet<T> = java.util.SortedSet<T> для JVM и что-то своё на других платформах
источник

AN

Alexander Nozik in Kotlin Community
Roman Elizarov
Дискусии нет, потому что это не баг, а особенности порядка инициализации. Его можно поменять так, чтобы конкретно этот код заработал, но тогда сломается какой-нибудь другой код. В общем случае нет решения которое бы всегда работало и каждый практический ЯП выбирает какой-то порядок и живет с ним и с тем кодом, который из-за него не работает. Не очень понятно какое на эту тему может быть обсуждение.
Ну решение вроде обсуждали. в связи с другой инициализационной проблемой. Детектировать проблемы с инициализацией и вешать ворнинги.
источник

VP

Vladimir Petrakovich in Kotlin Community
Alexander Nozik
Ну решение вроде обсуждали. в связи с другой инициализационной проблемой. Детектировать проблемы с инициализацией и вешать ворнинги.
... ведь IDE сейчас слишком быстро работает
источник

VP

Vladimir Petrakovich in Kotlin Community
Так-то я согласен, но это лишь одно из многих мест, где можно выстрелить себе в ногу порядком инициализации
источник

RE

Roman Elizarov in Kotlin Community
Проблема в том, что задача вообще не разрешима. Можно только в самых тривиальных случаях выдать warning (вроде где-то уже есть)
источник

AN

Alexander Nozik in Kotlin Community
Vladimir Petrakovich
Чтобы меньше проблем ловить, когда в stdlib появится
typealias SortedSet<T> = java.util.SortedSet<T> для JVM и что-то своё на других платформах
Тут есть несколько "но". Во-первых структурированную мультиплатформу очень недавно завезли и никто еще толком не умеет этим пользоваться (я пока не умею). В JVM типах часто есть не совсем адекватный для Kotlin API и часто имеет смысл его переписать. В случае с SortedSet проблемы с интеропом не велики, поскольку он редко встречается в API, так что переписать - это неплохое решение
источник