Т.е. должен ли я думать о том что код может исполняться в разных потоках когда использую корутины?

Не видел. Но что конкретно понимаете по "моделью памяти"

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

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

коллеги, немного концептуальный вопрос по мультиплатформе и expect

есть java класс для биндинга, у него есть статик методы, но они не биндятся в компаньон через actual, отсюда вопрос: как красивее и практичнее?
1. top level в файле
2. object <ClassName>Utils
3. object <ClassName>Ops
4. еще варианты

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

я бы объявил просто объект с таким же именем как класс, но нельзя(

@noraltavir у тебя хороший опыт мультиплатформы, как делаешь?

со стороны js та же проблема

там ts биндинги со статиками

в корутинах бесплатные (почти) методы синхранизации

Есть ещё вариант Myclass.Companion.foo

Т.е. к примеру, если я делаю flow, который использует suspend функцию для получения объектов, я могу смело читать данные из объекта без использования с моей стороны механизмов синхронизаций, как делал бы на java?

Думать о потоках надо, но я не понял, при чем тут модель памяти

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

я думаю отсылка к jvm и happens before

Да, но если у вас блокирующие операции то нужно уже подумать, есть Io Dispatcher, но он не всегда уместен

+

Я про экстеншен на компаньон. Если есть класс, то методы его компаньона можно сделать экстеншенами

ты мой спаситель :)

сейчас опробую

Разумеется в комоне должен быть хотя бы пустой компаньон