да у меня все ок с ним. используется давно в проекте. просто впервые решил buildString заюзать. должна быть какая-то связь с тем, что kotlinx.serialization кроссплатформенный ? мб его плагин виной

да у меня все ок с ним. используется давно в проекте. просто впервые решил buildString заюзать. должна быть какая-то связь с тем, что kotlinx.serialization кроссплатформенный ? мб его плагин виной

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

Может навести на какие-то мысли ./gradlew :app:dependencies | grep kotlin-stdlib

что-то я потерялся в этих результатах. но ничего критичного не вижу, везде форсится последняя версия

повыкидывал все зависимости кроме виновника проблемы, вообще чистота, версии котлина в kotlinx.serialization и у меня в проекте совпадают ?‍♂ но проблема остается

а они рядышком определены

Странненько, ибо в стдлибе одна декларация: https://github.com/JetBrains/kotlin/blob/1.2.40/libraries/stdlib/src/kotlin/text/StringBuilder.kt (да и expect-вариант подменяется actual typealias почти наверняка).

Точно, оно даже не в jdk* определено, а в jvm, что логично: https://github.com/JetBrains/kotlin/blob/1.2.40/libraries/stdlib/common/src/kotlin/TextH.kt https://github.com/JetBrains/kotlin/blob/1.2.40/libraries/stdlib/jvm/runtime/kotlin/text/TypeAliases.kt

Я правда без идей, откду могут браться разные декларации, если версия стдлиб одна. Может, завтра знающие люди помогут :)

Странненько, ибо в стдлибе одна декларация: https://github.com/JetBrains/kotlin/blob/1.2.40/libraries/stdlib/src/kotlin/text/StringBuilder.kt (да и expect-вариант подменяется actual typealias почти наверняка).

да, я затупил, сам только что решил перепроверить всё. одна находится в stdlib-common, другая просто в stdlib ? и они один в один, ну и serialization затягивает common

Ах же ж. Есть ещё просто stdlib, точно.

учитывая, что package одинаковые, не представляю, как это разрулить. мб исключить stdlib-common из зависмостей.. вообще проблема не глобальная, я могу и обойтись без этой функции, или свою написать. скорее просто интересно было

Без stdlib-common перестанет по идее работать то, что строится на мультиплатформе. Я бы попробовал наоборот выкинуть обычный stdlib.

а actual для jvm платформы не в нём определены? вообще не ориентируюсь в анатомии котлин либ

В common + jvm + опционально jdk8 должно быть всё то же, что есть в обычном stdlib.

хм. ладно, спасибо за помощь) поэкспериментирую потом

Да, правильно вы говорите, в stdlib и определены actual для JVM. Так что запутался я :) Сбило с толку, что есть libraries/stdlib/{common,jvm,jdk8}/src, а есть просто libraries/stdlib/src.

Правда, я не увидел, чтобы buildString в двух местах была определена. Завтра с десктопа посмотрю.

Правда, я не увидел, чтобы buildString в двух местах была определена. Завтра с десктопа посмотрю.

тоже не понимаю как оно устроено, в сорцах она определена в одном месте, но артефакты разные, причем в одном и для JVM и JS платформы функции, т.е. общие, в другом конкретно для JVM (их больше). если переходить по ctrl+ЛКМ в IDEA, то это видно.

похоже просто артефакты собираются из одного модуля, из одних исходников ?‍♂️

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

Подскажите, а почему нельзя использовать тернарный оператор в однострочной функции наподобие: fun foo(toUpperCase: Boolean, name: String) = toUpperCase ? name.toUpperCase() : name

Подскажите, а почему нельзя использовать тернарный оператор в однострочной функции наподобие: fun foo(toUpperCase: Boolean, name: String) = toUpperCase ? name.toUpperCase() : name

потому что в котлине if - это выражение можно написать: fun foo(toUpperCase: Boolean, name: String) = if(toUpperCase) name.toUpperCase() else name

конечно не так красиво, как с тернарным, но работает так же

Ага, спасибо! Я так и написал, просто хотелось понять подоплеку.

Подскажите, а почему нельзя использовать тернарный оператор в однострочной функции наподобие: fun foo(toUpperCase: Boolean, name: String) = toUpperCase ? name.toUpperCase() : name

Потому что в котлине его нет.

:D

потому что в котлине if - это выражение можно написать: fun foo(toUpperCase: Boolean, name: String) = if(toUpperCase) name.toUpperCase() else name

Лучше String.foo(toUpperCase: Boolean) = if (toUpperCase) toUpperCase() else this

чёт вообще странный код :)

Лучше String.foo(toUpperCase: Boolean) = if (toUpperCase) toUpperCase() else this

это уже дело вкуса, не люблю extension-функции плодить

https://discuss.kotlinlang.org/t/ternary-operator/2116/8 а вот кастати дискуссия по поводу тернарного оператора

это уже дело вкуса, не люблю extension-функции плодить

только если она действительно потом по всему проекту использоваться будет

Код просто пришедший из головы)

https://discuss.kotlinlang.org/t/ternary-operator/2116/8 а вот кастати дискуссия по поводу тернарного оператора

Шо, опять?!

Шо, опять?!

с 2016 и поныне ?

https://discuss.kotlinlang.org/t/ternary-operator/2116/8 а вот кастати дискуссия по поводу тернарного оператора

а почему его кстати нет то?

потому что конструкция if else его заменяет?

Конкретно моё мнение: 1. Впринципе if-else может делать тоже самое. 2. Тернарный оператор очень располагает к нечитаемому использованию: a ? b : c это обычно смотрится хорошо, наверное даже лучше, чем if (a) b else c a ? (b ? c : d) : e или какая-либо другая вложенность смотрится мягко говоря сложно. С помощью if-выражений можно расписать намного читабельнее. Итого - есть один простой кейс, в котором иногда тернарный оператор смотрится чуть-чуть лучше чем if-else (отмечу, что if-else смотрится неплохо при if-else выражениях, а не присваиваниях как в джаве). И есть куча кейсов, когда лучше не использовать тернарный оператор. И ради одного действительно небольшого улучшения нужно ли вводить целый оператор?

потому что конструкция if else его заменяет?

В этом чате уже отвечали, форварднул свой вариант :)

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

Ещё нюанс в том, что в PHP и Java он работает в разных направлениях.

Ещё нюанс в том, что в PHP и Java он работает в разных направлениях.

когда это кого-то смущало?

sealed классы например в C# и котлин тоже работают в совершенно разных направлениях

Опять 25

Пятница день сра@а

Так, а что картинки постить нельзя?

Почему то сообщение со скриншотом удалилось

Обычно с таким вопросом посылают в @android_ru

Но почему там @JvmOverloads?

Но почему там @JvmOverloads?

компилятор генерит три конструктора

потому что констрстор у вьюшки то не один

Обычно с таким вопросом посылают в @android_ru

имхо, тут чот с котлином

потому что констрстор у вьюшки то не один

Котлином разве нельзя хендлить такие кейсы? Без аннотаций

попробуй сгенерить 4 честных конструктора, которые вызывают супер с таким же количеством параметров

Снова здравствуйте

Котлином разве нельзя хендлить такие кейсы? Без аннотаций

насоздавать конструкторов руками никто не мешает

а точно не из-за того, что defStyleAttr = 0? =)

а точно не из-за того, что defStyleAttr = 0? =)

ты выиграл =))))

Всем спасибо. Привык когда вьюгруппы переопределяешь ноль туда кидать =)

а надо что?)

public AppCompatEditText(Context context, AttributeSet attrs) { this(context, attrs, R.attr.editTextStyle); }

а, да

да

ой, забыл в самом начале послать в @kotlin_mobile :)

sealed class Device( val id: Long, val lat: Double, val long: Double ) { class Camera(id: Long, lat: Double, long: Double) : Device(id, lat, long) class Sendor(id: Long, lat: Double, long: Double) : Device(id, lat, long) class Controller(id: Long, lat: Double, long: Double) : Device(id, lat, long) }

Можно ли как-то обойти эти повторения в конструкторе?

А то если что-то добавляется\меняется, то это надо в куче мест сделать. :(

запилить свойстка из базового класса в отдельный класс)

можно сделать поля в sealed class abstract, а в наследниках в конструкторе override

(такое себе конечно, но кода меньше)

запилить свойстка из базового класса в отдельный класс)

В смысле, использовать как аргумент некий отдельный класс содержащий в себе нужные нам?

В смысле, использовать как аргумент некий отдельный класс содержащий в себе нужные нам?

да, не перегружать класс обилием свойств

Всем привет, посижу почитаю вас тут тихонько ?

да, не перегружать класс обилием свойств

Норм идейка, спасибо

Конкретно моё мнение: 1. Впринципе if-else может делать тоже самое. 2. Тернарный оператор очень располагает к нечитаемому использованию: a ? b : c это обычно смотрится хорошо, наверное даже лучше, чем if (a) b else c a ? (b ? c : d) : e или какая-либо другая вложенность смотрится мягко говоря сложно. С помощью if-выражений можно расписать намного читабельнее. Итого - есть один простой кейс, в котором иногда тернарный оператор смотрится чуть-чуть лучше чем if-else (отмечу, что if-else смотрится неплохо при if-else выражениях, а не присваиваниях как в джаве). И есть куча кейсов, когда лучше не использовать тернарный оператор. И ради одного действительно небольшого улучшения нужно ли вводить целый оператор?

ну вообще говоря, Бреслав намекнул на Мобиусе, что тернарный оператор может появиться

И это страшно.

ну вообще говоря, Бреслав намекнул на Мобиусе, что тернарный оператор может появиться

ура

Кто-нибудь, сделайте голосование

Вот два варианта реакции сверху

Какое-то нечестное голосование было

ну вообще говоря, Бреслав намекнул на Мобиусе, что тернарный оператор может появиться

а мне казалось что он намекает на другое (на слайсы)

он сказал вопрос в том как заюзать ":"

ну вообще говоря, Бреслав намекнул на Мобиусе, что тернарный оператор может появиться

Имха, он очень нужен: ибо val v = if(...) ... else ... - вот за это в моём коде хочется почти и зжечь офис jb

и уже после этого решать вопрос про тернарник

Имха, он очень нужен: ибо val v = if(...) ... else ... - вот за это в моём коде хочется почти и зжечь офис jb

а чем поможет тернарник?

Имха, он очень нужен: ибо val v = if(...) ... else ... - вот за это в моём коде хочется почти и зжечь офис jb

и что тебе не нравится ?

он сказал вопрос в том как заюзать ":"

В элвисах же уже есть, а какой смысол ещё его куда-то пихать?