Визитор может?

Эт не визитер. Визитер в другую сторону работает.

ну да, давно названия не повторял) interface EventHandler { fun onEvent(event: Event) { when (event) { is AddEvent -> onEvent(event) is RemoveEvent -> onEvent(event) } } fun onEvent(event: AddEvent) = default(event) fun onEvent(event: RemoveEvent) = default(event) private fun default(event: Event) { println(event) } }

конкретный сервис реализует интерфейс, имплеменит нужные onEvent'ы

получается простыня в EventHandler, но что поделать

дак какая разница тогда?

Ну разница в том, что when только в одном месте?

Как было сказано - 100 ивентов всего, сервису интересны 10-20. В EventHandler простыня на 200 + C строк, в конкретном сервисе - просто вызовы методов/обработка

Если сервису нужно 10 ивентов - будет override 10 однострочников

раньше нужно было when распихать по всем сервисам

собирать все методы с аннотацией и генерить класс который внутри будет свитчить

ну в общем да, Ваш, @HeapyHop , метод вполне рабочий, даже круто что компилятор проверяет что все ли классы в свиче, но потом просто надоест поддерживать это руками и вернёмся к методу предложенному Dima способу (в реплае)

вообще меня изначально интересовало вообще это в байткоде можно сделать или нет

ну sealed класс будет умееть свитч по интам

так что будет быстро

ну sealed класс будет умееть свитч по интам

дада, я тоже уже об этом подумал

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

в джавке свитч по классам можно сделать разве только через class.getName()

а это жара с хешкодами

А тут anko-sqlite никто не использует? Не могу понять, оно experimental или уже нормальное и можно использовать?

если кому-то интересно, чем кончилась моя котовасия к корутиноканалами, то вот: у меня был кейз (коммуникация с гитхабом), мне надо было сделать несколько поисковых запросов, резульаты склеить в один канал, отфильтровать, потом по каждому элементу из рузальтата сделать отдельный запрос (тут надо было распараллелить, чтобы значительно ускорить этот процесс) и чтобы на выходе получился канал в котором бы появлялись результаты по мере их получения. Я сделал для клиента корутиновый метод send, затем реализовал метод send, который возвращает канал в котором были значения по одному на каждую страницу резульатов, затем я добавил метд merge, который просто последовательно копировал в один канал элементы из всех суб-каналов, затем я добавил метод map идентичный натуральному, только с дополнительным парамером capacity который позволял расширить канал, потом внутри мапа я запускал запросы в потоки async, на выходе получился канал Deferred-ов, сделал метод который разворачивал дефереды селектом и складывал в канал дальше, на выходе я это всё фильтрую, дистиктю и отдаю из сервиса https://gist.github.com/fogone/e940de35f755c13299a65733c4b3be59

Сори за говнокод

Но суть я думаю передает

ReceiveChannel<T>.map так есть же такое в самой либе?

Я же в описании написал

Что он идентичный, только можно capacity передать

а распаралеливание не делал еще?

На нной итерации получится rx

а распаралеливание не делал еще?

Так сделал же

Просто распараллеливаются не все шаги, а только один

Мне так и надо было

См. fetchFullPrInfo

Не бейте за флуд только :)

хм, спс, наверное как раз то что надо мне

Да, всё так ?

Конечно хотелось бы, чтобы хорошо проработанные средства для распараллеливания были из коробки, думаю это вопрос времени

На нной итерации получится rx

А вот да. Кажется что на корутинах можно было и по проще написать, а не копировать рх

А вот да. Кажется что на корутинах можно было и по проще написать, а не копировать рх

Вот ссылка на код есть, напиши

Вот ссылка на код есть, напиши

Чет лень и ты все равно будешь не доволен, тк не будет “рx-вого чейна”

Я бы эталонным этот код не назвал, но даже и не смотря на это написать попроще боюсь не выйдет

Чет лень и ты все равно будешь не доволен, тк не будет “рx-вого чейна”

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

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

Декларативность, хорошая модуляризация и гибкость в изменении отдельных шагов, краткость, хорошая расширяемость готовыми операциям

если и свои проблемы, конечно

Имхо в RX единственное что важно тк его “поток событий”, который и отличает его от тех же промисов (те RX ~= Observable) А когда мы начинаем накручивать “бизнес логику” на операторах рx (или юзать Maybe/Single/Completable) - значит что где то мы свернули не туда.

а где тут бизнес-логика? получить данные-то это бизнес-логика?

Мердж, фильтрации и всякие хитрые объединения и изменение порядка

а тоже самое в sql-е тебя не смущает? часто бизнес-логику в sql-е пишешь?

Смущает конечно, но это уже не касается котлина и вообще это имхо.

а это вопрос не котлина, это вопрос изоляции

к тому же это всё равно придется сделать в этом сервисе, цепочкой или нет

если кому-то интересно, чем кончилась моя котовасия к корутиноканалами, то вот: у меня был кейз (коммуникация с гитхабом), мне надо было сделать несколько поисковых запросов, резульаты склеить в один канал, отфильтровать, потом по каждому элементу из рузальтата сделать отдельный запрос (тут надо было распараллелить, чтобы значительно ускорить этот процесс) и чтобы на выходе получился канал в котором бы появлялись результаты по мере их получения. Я сделал для клиента корутиновый метод send, затем реализовал метод send, который возвращает канал в котором были значения по одному на каждую страницу резульатов, затем я добавил метд merge, который просто последовательно копировал в один канал элементы из всех суб-каналов, затем я добавил метод map идентичный натуральному, только с дополнительным парамером capacity который позволял расширить канал, потом внутри мапа я запускал запросы в потоки async, на выходе получился канал Deferred-ов, сделал метод который разворачивал дефереды селектом и складывал в канал дальше, на выходе я это всё фильтрую, дистиктю и отдаю из сервиса https://gist.github.com/fogone/e940de35f755c13299a65733c4b3be59

а как задача звучит совсем верхнеуровнево? Если без каналов и тому подобного?

а как задача звучит совсем верхнеуровнево? Если без каналов и тому подобного?

получить пр-ы :-)

у проекта? или у ряда проектов?

а, проекты?

или пулл-реквесты?

пул-реквесты

да это по сути не так и важно

просто там целый флоу их получения

не просто запрос послать

поиском сначала ищутся пр-ы, потом по ним получаются детали

ну на входе получается список? Просто, насколько, я понял корутины-way - это написать последовательный код и дальше добавить саспенд модификаторов и соответствующих корутин-билдеров

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

см. код

выше

Вопрос по коду выше. В чём суть select с единственным .onAwait внутри? (метод `unwrap()`)

@relizarov Роман, подскажите, есть вообще какие-то примеры такого использования каналов? планируется ли расширять библиотеку готовыми средствами для распараллеливания идущих по каналу потоков?

@relizarov Роман, подскажите, есть вообще какие-то примеры такого использования каналов? планируется ли расширять библиотеку готовыми средствами для распараллеливания идущих по каналу потоков?

Тоже интересно + я бы еще дополнил вопрос о способах комбинирования и склеивания того, что в терминах rx называется hot и неизвестной длиной стрима.

Вопрос по коду выше. В чём суть select с единственным .onAwait внутри? (метод `unwrap()`)

да ни в чем, это от моих экспериментов осталось, я так понимаю, что это будет работать так же как: fun <T> ReceiveChannel<Deferred<T>>.unwrap() = produce { consumeEach { send(it.await()) } }

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

@relizarov Роман, подскажите, есть вообще какие-то примеры такого использования каналов? планируется ли расширять библиотеку готовыми средствами для распараллеливания идущих по каналу потоков?

есть тикет на распаралеливание https://github.com/Kotlin/kotlinx.coroutines/issues/172

Тоже интересно + я бы еще дополнил вопрос о способах комбинирования и склеивания того, что в терминах rx называется hot и неизвестной длиной стрима.

BroadcastChannel наверное нужен?

да ни в чем, это от моих экспериментов осталось, я так понимаю, что это будет работать так же как: fun <T> ReceiveChannel<Deferred<T>>.unwrap() = produce { consumeEach { send(it.await()) } }

Понял, я просто думал, что есть какое-то особенное поведение (пока так и не довелось использовать select самому). Тогда вроде как достаточно будет .map { it.await() }

Понял, я просто думал, что есть какое-то особенное поведение (пока так и не довелось использовать select самому). Тогда вроде как достаточно будет .map { it.await() }

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

а нельзя сделать 1 канал на несколько акторов?

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

Понял.

а нельзя сделать 1 канал на несколько акторов?

actor(...) сам создаёт канал, но в теории можно сделать свой аналог, принимающий его как параметр вместо capacity: https://github.com/Kotlin/kotlinx.coroutines/blob/ea4f2f3ac31ca7a4c80fd4afe7824b1ddf795c3c/core/kotlinx-coroutines-core/src/main/kotlin/kotlinx/coroutines/experimental/channels/Actor.kt#L84

а еще всё время хочется использовать generateSequence, но нельзя ?

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

я так понимаю параллельная обработка выглядит примерно так?(если мне нужно в одном потоке это делать) runBlocking { val channel = Channel<Int>() launch { for (i in 0..20) { channel.send(i) } channel.close() } (0..4) .map { i -> launch(Unconfined) { channel.consumeEach { delay(2000) val thread = Thread.currentThread().name println("$thread: i=$it coroutine=$i") } } } .forEach { it.join() } }

По идее первый channel.consumeEach выгребет все данные и все i от 1 до 4 ничего не получат.

ну оно работает)

Да, delay же точка саспенда. Логично.

даже если убрать delay то будет работать

ChannelIterator.next(): > Retrieves and removes the element from this channel suspending the caller while this channel isEmpty [...] По идее ж канал не должен успевать быть пустым. Теперь мне интересно, почему это работает, присоединюсь к ожиданию ответов.

Переключение ведь происходит не на каждом вызове suspend fun, верно?

У меня есть прототип метода, который получает деферы по мере из выполнения, он получает все что есть в канале и пытается селектить из всех них, когда значение приходит он его из пула удаляет и повторяет селект

Но это почему-то не работает

Все что есть, в смысле все что доступно

Это обычно < capacity

вброс: зачем вообще корутины, если есть rx?

Народ так завелся паралельными флоу - что я уже и не знаю ?

вброс: зачем вообще корутины, если есть rx?

Так рх не саспендится же, а так я прямо в этом флоу вызываю саспенд методы запросов

саспенд внутри на тредлупе работает7

Как асинхронный запрос в клиенте реализован это уже другой вопрос

Ребята, а может кто-то коротко и толково изложить, что есть это "suspend"? А то я не очень понимаю

Ребята, а может кто-то коротко и толково изложить, что есть это "suspend"? А то я не очень понимаю

Это такое место в методе где выполнение можно остановить и продолжить в любой момент

С того места где остановился