Подскажите, как из ktor приложения замутить сервис под Ubuntu? Может есть что-то готовое?

Гугл, линукс создание демона (сервиса)

или combineLatest, если тебе нужны оба значения, но тогда нужно гарантировать, что Observable стартанет с emit текущего значения

больше нравится combineLatest

Гугл, линукс создание демона (сервиса)

Там нада сделать конфиг и поместь в папку /etc/init.d

больше нравится combineLatest

тогда у Observable нужно сделать startWith

Подскажите, как из ktor приложения замутить сервис под Ubuntu? Может есть что-то готовое?

https://plugins.gradle.org/search?term=systemd По готовым плагинам выбор небольшой — аж один, и тот rpm-ы делает. Но в целом это должно без особых проблем решаться с shadowjar — пинаете shadowDistZip, пишете к нему небольшой .service-файл для systemd (это действительно несложная задача, не бойтесь вникнуть), и пакете при надобности оба компонента в deb (тут чуть сложнее, вопрос в формировании папочки debian с конфигами и скриптами и правильных флагах для вызова debuild, который из этого конечный дистр сделает).

тогда у Observable нужно сделать startWith

зачем?

тогда у Observable нужно сделать startWith

мне нужно сделать 1 обсервабл, потом 2 обсервабл, потом в 3 combineLatest, так?

Спасибо, Андрей. Попробую

зачем?

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

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

Нет

Нет

хорошо, не изменятся, а заэмитятся, если быть точным

хорошо, не изменятся, а заэмитятся, если быть точным

Нет, достаточно ивента с одного источника

Обратитесь к документации, вы описываете сейчас zip

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

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

Нет, достаточно ивента с одного источника

прав, на то оно и combineLatest

Обратитесь к документации, вы описываете сейчас zip

взаимно, http://rxmarbles.com/#combineLatest

взаимно, http://rxmarbles.com/#combineLatest

тут всё как сказал @discipuli

тут всё как сказал @discipuli

посмотрите ссылку

посмотрите ссылку

так я по выводам из той картинки и отвечаю

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

погугли) или в личку

меняется один источник — эмитится новое значение

погугли) или в личку

Тогда расскажите отличие между zip?

меняется один источник — эмитится новое значение

первый эмит нового потока появляется после эмита с обоих потоков.

первый да

и второй

и третий

не-не

нет. второй и третий заберет предыдущий заэмиченный с первого потока

и скомбинит с новым

zip эмитит только когда оба заэмитили же ну

и скомбинит с новым

+

zip эмитит только когда оба заэмитили же ну

+

zip эмитит только когда оба заэмитили же ну

я про combineLatest ?

а я мимопроходил и влез в разговорм не понимая о чем кто говорит ?

а я мимопроходил и влез в разговорм не понимая о чем кто говорит ?

+1 тоже так всегда делаю ?

А можно как-то делегировать в поле, которое инициализируется внутри класса, а не параметром конструктора? interface Interface { fun method() } class Trait: Interface { override fun method() {} } // Работает class TypeA(private val impl: Trait) : Interface by impl { } // Не хотит. Unresolved reference: impl class TypeB: Interface by impl { private val impl = Trait() }

А можно как-то делегировать в поле, которое инициализируется внутри класса, а не параметром конструктора? interface Interface { fun method() } class Trait: Interface { override fun method() {} } // Работает class TypeA(private val impl: Trait) : Interface by impl { } // Не хотит. Unresolved reference: impl class TypeB: Interface by impl { private val impl = Trait() }

Естественно только вовне можно так делать. Иначе – увы и ах, у вас объект то еще не будет инициализиpoван на моменте делегиpoвания

Хм. Тогда такой вопрос. Как сделать инстанцирование покрасивше? class TypeA(private val impl: Trait) : Interface by impl fun typeA() = TypeA(Trait());

Естественно только вовне можно так делать. Иначе – увы и ах, у вас объект то еще не будет инициализиpoван на моменте делегиpoвания

open-методы не запрещают вызывать, хотя и не рекомендуют. Тут картина похожая (хотя я не представляю себе, зачем такое может быть нужно).

просто эта фича не развивается, тяжело с ней)

Хм. Тогда такой вопрос. Как сделать инстанцирование покрасивше? class TypeA(private val impl: Trait) : Interface by impl fun typeA() = TypeA(Trait());

Примерно так у себя и делаю, только конструктор ещё сделал internal.

Примерно так у себя и делаю, только конструктор ещё сделал internal.

Вот так будет православно, или лучше первый вариант и internal constructor? class TypeA private constructor(private val impl: Trait) : Interface by impl { companion object { fun new() = TypeA(Trait()) } }

можно второй конструктор или одноимённый фабричный метод

Вот так будет православно, или лучше первый вариант и internal constructor? class TypeA private constructor(private val impl: Trait) : Interface by impl { companion object { fun new() = TypeA(Trait()) } }

Если так, то можно fun new() превратить в operator fun invoke(), дабы получить из компаньона фабрику красивенькую.

Ну а вообще на свой вкус, тут единого мнения нету.

В kotlinx.coroutines, к примеру, используется top-level функция fun Channel(...): Channel вместо фабрики-компаньона.

О, вот так красивенько получается :) Спасибо! class TypeA private constructor (private val impl: Trait) : Interface by impl { constructor(): this(Trait()) }

не переносите открывающую фигурную скобку плиз

О, вот так красивенько получается :) Спасибо! class TypeA private constructor (private val impl: Trait) : Interface by impl { constructor(): this(Trait()) }

Это какой-то извpащенный способ создать декоpатоp?

глаза болят

class TypeA private constructor (private val impl: Trait) : Interface by impl { constructor(): this(Trait()) } Вот так?

О, вот так красивенько получается :) Спасибо! class TypeA private constructor (private val impl: Trait) : Interface by impl { constructor(): this(Trait()) }

Так даже лучше, да. Сходил бы свой вариант переписать, только у меня он волей случая уже в синглтон превратился, о чём я забыл (да простит меня @Harmonizr за упоминание синглтонов всуе).

Это какой-то извpащенный способ создать декоpатоp?

Это извращённый способ эмулировать трейты))

Так даже лучше, да. Сходил бы свой вариант переписать, только у меня он волей случая уже в синглтон превратился, о чём я забыл (да простит меня @Harmonizr за упоминание синглтонов всуе).

лишь бы он был deeply immutable / stateless :)

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

Это извращённый способ эмулировать трейты))

Слишком извpащенный, кмк. Pади чего хоть?

лишь бы он был deeply immutable / stateless :)

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

?

Слишком извpащенный, кмк. Pади чего хоть?

Как менее извращённо это делать?) Пока что ковыряю язык как таковой, смотрю, что как делается, что делается не так, как привычно

О, вот так красивенько получается :) Спасибо! class TypeA private constructor (private val impl: Trait) : Interface by impl { constructor(): this(Trait()) }

А чем вам дефолт значения не понравились? interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA(private val impl: Interface = Trait()) : Interface by impl

Слишком извpащенный, кмк. Pади чего хоть?

Иногда хочется множественного наследования

Как менее извращённо это делать?) Пока что ковыряю язык как таковой, смотрю, что как делается, что делается не так, как привычно

Сейчас, если у меня пpавильное пpедставление в голове, накидаю пpимеp (постаpаюсь).

Иногда хочется множественного наследования

Вот да) Но понимаешь, что это зло.

А чем вам дефолт значения не понравились? interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA(private val impl: Interface = Trait()) : Interface by impl

что эта строчка значит Interface by impl

А чем вам дефолт значения не понравились? interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA(private val impl: Interface = Trait()) : Interface by impl

Его при инстанцировании можно попортить

ERROR: S client not available

я не шарю

что эта строчка значит Interface by impl

Делегация, встроенная в язык.

что эта строчка значит Interface by impl

Это значит, что все вызовы к методам из интерфейса Interface будут делегированы в impl

что эта строчка значит Interface by impl

реализует интерфейс делегированием на impl

Как много способов сказать одно и то же)))

Вот да) Но понимаешь, что это зло.

Мы так большие презентеры на переиспользуемые части пилим

только я при этом все равно не понял

только я при этом все равно не понял

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

https://kotlinlang.org/docs/reference/delegation.html#implementation-by-delegation

Короткий способ сделать так: interface Interface { fun method(): Int } class Impl: Interface { override fun method() = 42 } class Foo: Interface { private val impl = Impl() override fun method() = impl.method() }

только я при этом все равно не понял

Ну то есть TypeA реализует интерфейс Interface, но все обращения к методам Interface вызывают соответствующие методы для impl

я знаю в чем ваша проблема

вы пытаетесь писать документацию в википедию простому алкашу

Ну, делегирование - это когда твой дядя просит твоего батю по пути сгонять за сигами, а батя за сигами отправляет тебя

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

То есть не надо руками каждую операцию копипастить.

вы пытаетесь писать документацию в википедию простому алкашу

это не наша проблема)

я еще в шарпе так и понял что за делегаты такие

так что я в общем с этим не знаком

я еще в шарпе так и понял что за делегаты такие

видимо, не очень-то и хотелось

К шарповым делегатам это, в целом, никакого отношения не имеет.

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

Там это просто список коллбеков, одна сторона туда закидывает свои коллбеки, другая сторона их все одним махом вызывает.

По крайней мере, мне так запомнилось.

А чем это удобнее передачи лямбды? o.O

Типа там списком?

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

Но я ж грю, я шарп видел сто лет назад в универе и могу сильно ошибаться :D

передача лямбды это уже яваскрипт какойто

reentrantReadWriteLock.write { // blah blah }

Передача лямбды)

А чем вам дефолт значения не понравились? interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA(private val impl: Interface = Trait()) : Interface by impl

Кстати, а именно в этом ваpианте пpинципиально наличие impl в TypeA (если его не будет пpи схoжем поведении, вас это устpoит?)