Какие к черту акторы для счётчиков ?

actor { … }

Может взять нормальный AtomicLongAdder и не выеживаться все-таки?)

Это часть другой большой логики. Мне нужна подписка на этот счетчик.

Если тебе нужна штука, которая будет работать на корутинах и что-то считать

Это часть другой большой логики. Мне нужна подписка на этот счетчик.

Тогда актор вполне норм решение, если остальная логика работает тоже на каналах

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

Я семафор как раз через актор реализовывал

Это будет потокобезопасно?

Я думаю, что да это будет потокобезопасно... В один момент времени читает канал только один поток, не важно сколько у меня там потоков...

Возможно сейчас в преддверии релиза там всё получше

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

Возможно сейчас в преддверии релиза там всё получше

Тут мелькал человек, который говорил, что они что-то вроде utils делают для корутин

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

Вроде же миграция есть

0.25.3 -> 1.0.0

Такой миграции нет.

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

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

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

кажись что да

будет только куча сущностей лишних

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

Думаю, что и не только для ui

кажись что да

Я вот не уверен. Больше похоже что будет куча объектов со своим состоянием в памяти, а не "поток событий".

Я вот не уверен. Больше похоже что будет куча объектов со своим состоянием в памяти, а не "поток событий".

на самом деле это как написать

можно и стейтлесс акторы делать

Я вот не уверен. Больше похоже что будет куча объектов со своим состоянием в памяти, а не "поток событий".

Потоки событий это каналы, они как раз как рх. Сами акторы они очень разные могут быть

У рх тоже всегда есть источник событий и их слушатель

можно и стейтлесс акторы делать

Ну это же какие-то не "канонические" акторы получаются. Я думал, это что-то про тру-ооп с инкапсуляцией)) и обменом сообщений.

Ну это же какие-то не "канонические" акторы получаются. Я думал, это что-то про тру-ооп с инкапсуляцией)) и обменом сообщений.

ну так разве не может быть ооп без стейта внутри?

какой-нибудь "Умножитель" например

или Strategy

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

какой-нибудь "Умножитель" например

Больше похоже на pure-function

Больше похоже на pure-function

в ооп функции- объекты)

Больше похоже на pure-function

https://ru-lambda.livejournal.com/27669.html

Больше похоже на pure-function

Главное чтобы не было как в акке

И как там?

И как там?

Чуть более заморочено чем хотелось бы

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

Ну там не так сложно. По-сути, контекст перенесён в Dispatchers. В тех суспенд функциях, в которых запускаются корутины, нужно вызывать coroutineScope. Например: suspend fun foo(): Bar = coroutineScope { ... async { ... } } Остальные корутины, верхнеуровневые, нужно запускать либо через GlobalScope, либо в класс(е/ах) наследоваться от Scope (забыл точное название, мб CoroutineScope, что-то такое) и переопределить coroutineContext. Например: class Foo : Scope { private lateinit var job: Job override val coroutineContext: ... get() = job + Dispatchers.Default fun start() { job = Job() } fun finish () { job.cancel() } }

Ну это наброски

Здравствуйте! У меня появился такой вопрос. В андроид приложении я взаимодействую с бэкендом на ASP.NET и в JSON-файлах мне приходят ключи вида "id": "854a8d07-5a37-4e1e-8547-40ce891b3663". Скажите допустимо ли будет хранить такие ключи в виде строк в базе данных или есть како-нибудь лучший способ хранения?

У многих БД есть специальный тип UUID

бой за секьюрити уже проигран, еще не начавшись, кмк

лол. где он тогда не проигран? (правильный ответ - в https с тем же json)

У многих БД есть специальный тип UUID

+

И как там?

В акке то? Там нетипизированные акторы - это по сути функция Any -> Unit

Есть Akka.Typed

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

ХЗ, кстати, почему Ligthbend (тогда ещё Typesafe) сразу не озаботилась типизацией

ХЗ, кстати, почему Ligthbend (тогда ещё Typesafe) сразу не озаботилась типизацией

Озоботились, это уже 5ая экспериментальная версия

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

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

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

Они вобщем то сделали тайпсейф штуки поверх нетипизированные акторов

Добрый день! Посоветуйте фреймворк (серверной части) для SPA-приложения с сервером на Котлин

пока рассматриваю ktor

пока рассматриваю ktor

правильным курсом движетесь товарищ Ирина

Всем доброе утро. У меня студи обновила версию котлина с 1.2.41 до 1.2.71. И теперь такая lazy-инициализация не работает val appComponent: AppComponent by lazy { DaggerAppComponent.builder() .appModule(AppModule(context)) .build() } В lazy компилятор выдает ошибку Type interference failed. Я не могу понять что за тип и как я его должен укахать

Подскажите как решить эту штуку

Метод билд точно возвращает тип AppComponent?

Затыки с type inference решаются вынесением промежуточных вычислений в переменную с явным типом. Рано или поздно всплывёт какая-нибудь дичь в типах. После решения проблемы переменные можно заинлайнить обратно

кто-то использовал http://ebean-orm.github.io/ ?

о, они jpa поддержку котлина заявляют??? норм)

http://ebean-orm.github.io/docs/kotlin/ - TODO! ОГОНЬ!

это что, новый hibernate?

http://ebean-orm.github.io/docs/getting-started/kotlin-first-entity

это что, новый hibernate?

он наоборот очень стар

это что, новый hibernate?

Current version - 11.22.10

ну первый коммит committed on 13 Sep 2012

хм, да, я думал старше

у них прикольно, а-ля querydsl сразу в ORM http://ebean-orm.github.io/docs/query/background/typesafe

У них в примерах у сущностей все поля var, отвратительно

о, они jpa поддержку котлина заявляют??? норм)

Как-будто что-то хорошее. Вот кстати, куда еще можно бежать с jpa/hibernate https://github.com/requery/requery

Как-будто что-то хорошее. Вот кстати, куда еще можно бежать с jpa/hibernate https://github.com/requery/requery

я ничего плохого в JPA не вижу

я ничего плохого в JPA не вижу

я согласен с мнением, что это такой очередной ejb2

я ничего плохого в JPA не вижу

https://blog.jooq.org/2015/04/15/how-jpa-2-1-has-become-the-new-ejb-2-0/

к тому же его, как и хибер, не выбросят, а большинство остальных фреймворков могут кануть в лету

https://blog.jooq.org/2015/04/15/how-jpa-2-1-has-become-the-new-ejb-2-0/

упаси боже, никто эти аннотации не использует

все используют только маппинги и нормальные посотрители запросов, либо spring data

https://blog.jooq.org/2015/04/15/how-jpa-2-1-has-become-the-new-ejb-2-0/

KPACUBO

https://blog.jooq.org/2015/04/15/how-jpa-2-1-has-become-the-new-ejb-2-0/

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

кстати жук то генерит маппинг классы?

кстати жук то генерит маппинг классы?

А? что? Какую-то примитивную форму

Book и Author я так понимаю маппинги, BookRecord и AuthorRecord - сущности

первые два генерятся или пишутся руками?

Book и Author я так понимаю маппинги, BookRecord и AuthorRecord - сущности

Первое - это описания таблиц

первые два генерятся или пишутся руками?

и так и так

это ведь JOOQ ?

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

Аннотации хороши в статически типизированном языке только как мета информация для дополнительных проверок компилятором/статическими анализаторами кода (@Override, @Deprecated, @FunctionalInterface и иже с ними). Для описания мапингов и прочих архитектурных связок их использовать плохо, так как это не прозрачно и не типо безопасно (большинство таких аннотаций обрабатывается в рантайм рефлексией, которая непрозрачна и не типобезопасна). Тем более это верно для Kotlin, где архитектура приложения может описываться на том же языке, что и алгоритмы, благодаря наличию дженериков, функций высших порядков и прочих высокоуровневых абстракций. Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком?

Аннотации хороши в статически типизированном языке только как мета информация для дополнительных проверок компилятором/статическими анализаторами кода (@Override, @Deprecated, @FunctionalInterface и иже с ними). Для описания мапингов и прочих архитектурных связок их использовать плохо, так как это не прозрачно и не типо безопасно (большинство таких аннотаций обрабатывается в рантайм рефлексией, которая непрозрачна и не типобезопасна). Тем более это верно для Kotlin, где архитектура приложения может описываться на том же языке, что и алгоритмы, благодаря наличию дженериков, функций высших порядков и прочих высокоуровневых абстракций. Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком?

Дичайше плюсую (и разрабатываю очередной способ выражать это всё языком).

Аннотации хороши в статически типизированном языке только как мета информация для дополнительных проверок компилятором/статическими анализаторами кода (@Override, @Deprecated, @FunctionalInterface и иже с ними). Для описания мапингов и прочих архитектурных связок их использовать плохо, так как это не прозрачно и не типо безопасно (большинство таких аннотаций обрабатывается в рантайм рефлексией, которая непрозрачна и не типобезопасна). Тем более это верно для Kotlin, где архитектура приложения может описываться на том же языке, что и алгоритмы, благодаря наличию дженериков, функций высших порядков и прочих высокоуровневых абстракций. Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком?

+1. Молитесь, чтобы в обработке хиберовского @OneToMany никогда не закрадывалось багов. Закрадётся - взвоешь разбираться, почему оно упало

Аннотации хороши в статически типизированном языке только как мета информация для дополнительных проверок компилятором/статическими анализаторами кода (@Override, @Deprecated, @FunctionalInterface и иже с ними). Для описания мапингов и прочих архитектурных связок их использовать плохо, так как это не прозрачно и не типо безопасно (большинство таких аннотаций обрабатывается в рантайм рефлексией, которая непрозрачна и не типобезопасна). Тем более это верно для Kotlin, где архитектура приложения может описываться на том же языке, что и алгоритмы, благодаря наличию дженериков, функций высших порядков и прочих высокоуровневых абстракций. Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком?

Это верно, проблема только в том, что сейчас не такой уж большой выбор фреймворков типа экспозед

Аннотации хороши в статически типизированном языке только как мета информация для дополнительных проверок компилятором/статическими анализаторами кода (@Override, @Deprecated, @FunctionalInterface и иже с ними). Для описания мапингов и прочих архитектурных связок их использовать плохо, так как это не прозрачно и не типо безопасно (большинство таких аннотаций обрабатывается в рантайм рефлексией, которая непрозрачна и не типобезопасна). Тем более это верно для Kotlin, где архитектура приложения может описываться на том же языке, что и алгоритмы, благодаря наличию дженериков, функций высших порядков и прочих высокоуровневых абстракций. Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком?

Но хочется придумать таки (нормальный!) способ к полям добавлять метаданные.

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

Он очень неудобный для котлина, однако он есть

Аннотации хороши в статически типизированном языке только как мета информация для дополнительных проверок компилятором/статическими анализаторами кода (@Override, @Deprecated, @FunctionalInterface и иже с ними). Для описания мапингов и прочих архитектурных связок их использовать плохо, так как это не прозрачно и не типо безопасно (большинство таких аннотаций обрабатывается в рантайм рефлексией, которая непрозрачна и не типобезопасна). Тем более это верно для Kotlin, где архитектура приложения может описываться на том же языке, что и алгоритмы, благодаря наличию дженериков, функций высших порядков и прочих высокоуровневых абстракций. Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком?

>Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком? Думаю, вопрос в определённом сорте удобства: людям нравится иметь это под рукой прямо в том же месте, где сами сущности, к которым это относится, объявляются - условно, видеть @Transactional в спринге в тех компонентах, где применяется соответствующая аннотации логика, а не в AbstractPersistenceTransactionConfigFactoryBean (утрирую!) где-то очень далеко. Трейд-офф типобезопасности/компайл-тайм корректности приложения с простотой поддержания контекста при разработке и собственно разработки.

Но хочется придумать таки (нормальный!) способ к полям добавлять метаданные.

Думается мне, тяжко это будет, пока поля реализованы так, как реализованы - без внятной модели метапрограммирования с их использованием (рефлексию не предлагать). В каком-то приближение линзы-телескопы из ФП могут это дать, но в очень начальном приближении

>Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком? Думаю, вопрос в определённом сорте удобства: людям нравится иметь это под рукой прямо в том же месте, где сами сущности, к которым это относится, объявляются - условно, видеть @Transactional в спринге в тех компонентах, где применяется соответствующая аннотации логика, а не в AbstractPersistenceTransactionConfigFactoryBean (утрирую!) где-то очень далеко. Трейд-офф типобезопасности/компайл-тайм корректности приложения с простотой поддержания контекста при разработке и собственно разработки.

Ну, это может быть заменено на вызов функции типа fun a() = transaction {..}

Думается мне, тяжко это будет, пока поля реализованы так, как реализованы - без внятной модели метапрограммирования с их использованием (рефлексию не предлагать). В каком-то приближение линзы-телескопы из ФП могут это дать, но в очень начальном приближении

Я сейчас для DTO испольую другую модель: объявление поля — это объект; DTO в обмен на объявление поля выдаёт его значение (типа геттер такой). Базовые данные спокойно влазят в объявление поля; проблема в том, что на сериализованую форму и на объектную модель это мапптся по-разному. И имена одних полей иногда должны различаться для разных сред.