и все хорошо работает

можно еще интерфейс сделать с дефолтным методом)

ну для sealed классов это врядли подойдет, или?

Да мне хватает вот такого: object OutUsbOpen: OutputCommand() { override fun toString(): String = "${javaClass.simpleName}()" } Просто вот такого -- строк 50, что смущает.

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

Альтернативы?

Часть команд с параметрами, потому обычные data class-ы с автосгенерированными equals / hashCode / toString, для команд без параметров других вариантов не вижу -- для object не надо определять сравнение вообще, он и так один, остаётся только toString() -- но как я уже отметил, это косметика (логи приятнее), а не решение задачи, так что с этим можно жить.

Альтернативы?

ну я написал альтернативу

ну я написал альтернативу

А почему object с toString по вашему мнению -- странно, а class со всеми тремя методами -- нет?

может я и ошибаюсь, и это только дело вкуса. Вот проверил документацию - https://kotlinlang.org/docs/reference/sealed-classes.html - они сами тут object используют

а зачем toString() переопределять у него?

так что сорри весли ввел в заблуждение

я просто написал как сам использую ?

Andrew Mikhaylov: ... .toString() выдаёт qualified name и instance id, которые выглядят так себе -- хотелось бы видеть MyClass() вместо com.example.company.project.package.MyClass@601d768d.

ну это я увидел, но это чисто чтобы красиво? или какаято функциональная ценность? ? (мало ли, может вы в текстовом поле выводите это)

Логи, косметика, я ж писал.

В общем, я суть уловил, вариантов нет, но проблемой не является, так что всё хорошо :)

Что мешает для этих 50 object'ов сделать один общий родитель с equals/hashCode/toString?

Что мешает для этих 50 object'ов сделать один общий родитель с equals/hashCode/toString?

Прекрасный вопрос, никто же не мешает определить toString у базового sealed class -- object-ы подхватят его, а data class-ы переопределят сами. Спасибо, не сообразил, что базовый sealed class может быть не просто маркером.

Прекрасный вопрос, никто же не мешает определить toString у базового sealed class -- object-ы подхватят его, а data class-ы переопределят сами. Спасибо, не сообразил, что базовый sealed class может быть не просто маркером.

я тебе сразу это написал, может плохо выразился

пытаюсь в onCreate проверить if (savedInstanceState==null)

не работает

override fun onCreate(savedInstanceState: Bundle?)

Что не работает?

Смарт каст?

-> @android_ru или @kotlin_mobile

товарищи! Кто-то пробывал юзать kotlin - native, как впечатления? стоит ли пробывать?

товарищи! Кто-то пробывал юзать kotlin - native, как впечатления? стоит ли пробывать?

Да, я пробовал, очень хорошие впечатления, но нужно понимать, что это ещё не релиз

Ребят, а coroutin(ы) предпочтительнее использовать, чем RxJava? Или от чего это зависит

от задачи

от задачи

а есть статейка или информация в каком случае, что лучше применять?

а есть статейка или информация в каком случае, что лучше применять?

Корутины удобны для пследовательного асинхронного кода. Rx — для прыгания между разными потоками. Но это моё мнение, и какой-то чёткой грани, вероятно, нет.

Корутины удобны для пследовательного асинхронного кода. Rx — для прыгания между разными потоками. Но это моё мнение, и какой-то чёткой грани, вероятно, нет.

с каналами и акторами можно тоже вполне прыгать)

с каналами и акторами можно тоже вполне прыгать)

Вообще да. Хм, наверное, чисто дело привычки.

а есть статейка или информация в каком случае, что лучше применять?

https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/coroutines-guide-reactive.md Сравнение рх и каналов -- полезный раздел.

https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/coroutines-guide-reactive.md Сравнение рх и каналов -- полезный раздел.

Спасибо!

как мы тут выяснили, сейчас у каналов не до конца проработана работа с распараллеливанием задач

@fogone  Просто я хотел бы узнать насколько корутины лучше\есть преимущества перед RxJava. Для сетевых запросов\БД и последущей обработки результа

Скинули статью, надеюсь она ответит на вопросы

Да, это всё ещё не до конца стабилизированное и не покрывающее все юзкейсы апи, у рх есть уйма операторов, которых нету у каналов, но каналы прекрасны тем, что они о корутинах с вытекающим из этого способом применения.

Для кого-то это минус, для кого-то -- плюс.

да, сейчас у рх намного более развита инфраструктура, но я думаю у каналов со временем тоже всё появится

из за корутин каналы намного проще устроены чем обсервабл, использовать их намного приятнее из за этого. И писать расширения тоже

Да, это всё ещё не до конца стабилизированное и не покрывающее все юзкейсы апи, у рх есть уйма операторов, которых нету у каналов, но каналы прекрасны тем, что они о корутинах с вытекающим из этого способом применения.

> рх есть уйма операторов, которых нету у каналов Хм, вроде как раз и хотели уйти от запоминания 100500 операторв (по словам Романа), а оно вон как. Еще и Вортон пытается напилить RX-на-корутина.

> рх есть уйма операторов, которых нету у каналов Хм, вроде как раз и хотели уйти от запоминания 100500 операторв (по словам Романа), а оно вон как. Еще и Вортон пытается напилить RX-на-корутина.

Вы ж недавно пытались (и Вортон в слаке с кем-то пытался) сочинить debounce вроде бы. 100500 -- перебор, конечно, но пока и вот таких важных нет. Касательно непосредственно 100500 -- потому я и говорю, что для кого-то это плюс, для кого-то минус. Я тут в чате припоминаю мнение, что эти ваши корутины -- императивщина и ненужно, ибо есть реактивные стримы :)

А когда пытаются императивщину натянуть на рх - то получаются просто адовые спагетти. Честно не понимаю зачем из каналов делать рх, когда можно просто взять рх (если такая любой везде его натягивать) + расширения от корутин.

А в новых версиях implicit преобразований к нужным типам еще не завозили случаем?

А в новых версиях implicit преобразований к нужным типам еще не завозили случаем?

Может, не надо?)

Да ладно, удобно было бы. Не сильно люблю implicit-ы, но в некоторых случаях код они сокращают и упрощают :)

А в новых версиях implicit преобразований к нужным типам еще не завозили случаем?

Да лан, там их вон в скале частично убирают тк даже Мартин признал их ошибкой

Да лан, там их вон в скале частично убирают тк даже Мартин признал их ошибкой

Черт знает. Мне исключительно понравилось их использовать. Исчезла куча адских вызовов мапперов, тонну параметров не нужно передавать в конструктор, ну и так далее.

Черт знает. Мне исключительно понравилось их использовать. Исчезла куча адских вызовов мапперов, тонну параметров не нужно передавать в конструктор, ну и так далее.

> тонну параметров не нужно передавать в конструктор А как тут помогает имлисит-преобразования или просто про имлиситы? (это да удобно местами)

> тонну параметров не нужно передавать в конструктор А как тут помогает имлисит-преобразования или просто про имлиситы? (это да удобно местами)

Именно тут – просто имплиситы. А вот для избегания кучи преобразования типов – преобразования как-раз помогают (ща прям кейс закину, в котором было бы удобно :))

Мне очень нравятся extension функции для таких штук, но постоянно юзать даже экстеншны подбешивает :) https://gist.github.com/komigor/bf53fbfbff292cf863ee2e153e4d5516

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

хорошо хоть идея подчеркивает их, но всё равно есть грань, где явное всегда лучше неявного

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

Да ладно, удобно было бы. Не сильно люблю implicit-ы, но в некоторых случаях код они сокращают и упрощают :)

Оу. А о чём это вы вообще? Можно какой-то линк на эту тему?

Оу. А о чём это вы вообще? Можно какой-то линк на эту тему?

https://docs.scala-lang.org/tour/implicit-parameters.html https://stackoverflow.com/questions/10375633/understanding-implicit-in-scala

Благодарю

кто пробывал kotlin\native и Qt?

кто пробывал kotlin\native и Qt?

https://t.me/kotlin_lang/51128

товарищи! Кто-то пробывал юзать kotlin - native, как впечатления? стоит ли пробывать?

со сборкой проблематично, а так я пока только начал

Привет всем, у меня вопрос по котлину. Хочу такой код: var oldFiles : MutableMap<Path, ChangeType>? = null; synchronized(this) { if (files.isNotEmpty()) { oldFiles = files; files = HashMap() } } if (oldFiles != null) process(oldFiles) Т.е. смысл в том, что я в отдельном потоке проверяю, что некая переменная класса типа MutableMap не пуста, и если так, то заменяю ее на пустую, а для певоначальной вне блока synchronized уже выполняю метод обработки. Но это не компилируется из-за того, что в отличие от жавы в котлине это кложура: Error:(31, 25) Kotlin: Smart cast to 'MutableMap<Path, DirObserver.ChangeType>' is impossible, because 'oldFiles' is a local variable that is captured by a changing closure Как быть?

Из synchronized можно вернуть значение

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/synchronized.html

Привет всем, у меня вопрос по котлину. Хочу такой код: var oldFiles : MutableMap<Path, ChangeType>? = null; synchronized(this) { if (files.isNotEmpty()) { oldFiles = files; files = HashMap() } } if (oldFiles != null) process(oldFiles) Т.е. смысл в том, что я в отдельном потоке проверяю, что некая переменная класса типа MutableMap не пуста, и если так, то заменяю ее на пустую, а для певоначальной вне блока synchronized уже выполняю метод обработки. Но это не компилируется из-за того, что в отличие от жавы в котлине это кложура: Error:(31, 25) Kotlin: Smart cast to 'MutableMap<Path, DirObserver.ChangeType>' is impossible, because 'oldFiles' is a local variable that is captured by a changing closure Как быть?

oldFiles?.let(::process)

Спасибо

насколько это generic-hell?) abstract class ViperFragment<Model, Event, V: IView<Model, Event>, R: BaseRouter<*, *, *>, out P: ViperPresenter<Model, Event, V, R»: Fragment()

насколько это generic-hell?) abstract class ViperFragment<Model, Event, V: IView<Model, Event>, R: BaseRouter<*, *, *>, out P: ViperPresenter<Model, Event, V, R»: Fragment()

Жуть какая

насколько это generic-hell?) abstract class ViperFragment<Model, Event, V: IView<Model, Event>, R: BaseRouter<*, *, *>, out P: ViperPresenter<Model, Event, V, R»: Fragment()

это больше inheritance-hell

какие есть варианты для лимитов на ресурсы с корутинами и без? к примеру есть апишка, к которой можно посылать только скажем 4 одновременных запроса, к нам из веба пришло 2 клиента, которым нужно по 10 запросов к этой апишке сделать первое что приходит в голову это отдельный тред пул на 4 потока или семафора

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

я возможно не в ту сторону копаю даже?

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

Так можно же точно так же 4 потока работать

какие есть варианты для лимитов на ресурсы с корутинами и без? к примеру есть апишка, к которой можно посылать только скажем 4 одновременных запроса, к нам из веба пришло 2 клиента, которым нужно по 10 запросов к этой апишке сделать первое что приходит в голову это отдельный тред пул на 4 потока или семафора

Так можно создать ограниченный-пул и конвертнуть его в dispatcher. В .NET кстати есть класс SemaphoreSlim как раз для работы с async/await, он позволяет усыплять корутины сверх лимита. Наверное можно похожее и в котлин-корутины завести, хотя не понятно чем это лучше кастомного диспачера.

Тред пул не поможет, т.к. корутины на то и корутины, чтобы выполняться в большом количестве на маленьком количестве потоков. Недавно столкнулся с такой же задачей и не нашёл в kotlinx.coroutines ничего подходящего. Уже начал писать велосипед поверх Mutex.

Добрый вечер Недавно загорелся идеей изучить Kotlin для воплощения в жизнь одной из идей. На данный момент работал лишь с Python (речь про ООП), Jav'у не трогал и особого желания читать доки по этому языку ради изучения другого не имею. Пока не совсем понял пару вещей - Таки стоит ли мне смотреть в сторону Java (просто куда ни плюнь все гении пишут про байткод и прочие прелести конвертации в Java)? Если конечным продуктом является приложение для Android (а потом и IOS, но тут Swift выглядит более надёжно), то не стоит ли мне начать сразу с изучения работы с AndroidStudio? Заранее спасибо.

Добрый вечер Недавно загорелся идеей изучить Kotlin для воплощения в жизнь одной из идей. На данный момент работал лишь с Python (речь про ООП), Jav'у не трогал и особого желания читать доки по этому языку ради изучения другого не имею. Пока не совсем понял пару вещей - Таки стоит ли мне смотреть в сторону Java (просто куда ни плюнь все гении пишут про байткод и прочие прелести конвертации в Java)? Если конечным продуктом является приложение для Android (а потом и IOS, но тут Swift выглядит более надёжно), то не стоит ли мне начать сразу с изучения работы с AndroidStudio? Заранее спасибо.

Какова цель? Разработка под Android? Тогда Kotlin — лучший вариант, но знание Java всё же помогает, т. к. на ней написан и сам Android, и горы библиотек. Работа в Android Studio не имеет каких-то решительных отличий от работы в PyCharm, например.

Какова цель? Разработка под Android? Тогда Kotlin — лучший вариант, но знание Java всё же помогает, т. к. на ней написан и сам Android, и горы библиотек. Работа в Android Studio не имеет каких-то решительных отличий от работы в PyCharm, например.

Нет, я не очень горю желанием разрабатывать под Android на постоянной основе. Просто у меня есть проект, который требует взаимодействия с пользователем. Тк я не работал в сфере моб. разработки я выбрал телеграм и запилил бота на питоне. По мере развития проекта стало понятно, что нужно свое приложение (желательно не белый экран с парой кнопок, а красивое и приятное средство взаимодействия). + я лично хочу потрогать Kotlin и научиться работать с ним, как с наиболее прогрессивным языком из Java-семьи. Python классный, но уже приелся.

Нет, я не очень горю желанием разрабатывать под Android на постоянной основе. Просто у меня есть проект, который требует взаимодействия с пользователем. Тк я не работал в сфере моб. разработки я выбрал телеграм и запилил бота на питоне. По мере развития проекта стало понятно, что нужно свое приложение (желательно не белый экран с парой кнопок, а красивое и приятное средство взаимодействия). + я лично хочу потрогать Kotlin и научиться работать с ним, как с наиболее прогрессивным языком из Java-семьи. Python классный, но уже приелся.

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

конечно еще маловато поектов, но быстро набираю темп

Так можно создать ограниченный-пул и конвертнуть его в dispatcher. В .NET кстати есть класс SemaphoreSlim как раз для работы с async/await, он позволяет усыплять корутины сверх лимита. Наверное можно похожее и в котлин-корутины завести, хотя не понятно чем это лучше кастомного диспачера.

не хочу плодить пулы, корутины ж не для этого

Нет, я не очень горю желанием разрабатывать под Android на постоянной основе. Просто у меня есть проект, который требует взаимодействия с пользователем. Тк я не работал в сфере моб. разработки я выбрал телеграм и запилил бота на питоне. По мере развития проекта стало понятно, что нужно свое приложение (желательно не белый экран с парой кнопок, а красивое и приятное средство взаимодействия). + я лично хочу потрогать Kotlin и научиться работать с ним, как с наиболее прогрессивным языком из Java-семьи. Python классный, но уже приелся.

https://t.me/kotlin_mobile

Нет, я не очень горю желанием разрабатывать под Android на постоянной основе. Просто у меня есть проект, который требует взаимодействия с пользователем. Тк я не работал в сфере моб. разработки я выбрал телеграм и запилил бота на питоне. По мере развития проекта стало понятно, что нужно свое приложение (желательно не белый экран с парой кнопок, а красивое и приятное средство взаимодействия). + я лично хочу потрогать Kotlin и научиться работать с ним, как с наиболее прогрессивным языком из Java-семьи. Python классный, но уже приелся.

джаву учисо стороны андоида

поможет

Тред пул не поможет, т.к. корутины на то и корутины, чтобы выполняться в большом количестве на маленьком количестве потоков. Недавно столкнулся с такой же задачей и не нашёл в kotlinx.coroutines ничего подходящего. Уже начал писать велосипед поверх Mutex.

решил так, делаю SendChannel, пускаю N корутин которые его обрабатывают и постоянно запущены там где нужно использование делаю что-то в духе val results = produce<String> { for (i in 0..10) { channel.send(Job(i.toString(), this.channel)) } }

дебажить правда это то еще веселье

дебагер совсем не умеет работать