OC
я хочу чтобы пользователь вообще не догадывался, что его код реактивный\
Size: a a a
2018 August 20
ПФ
ну так map — операция над коллекцией
ПФ
мне кажется можно сделать так, чтобы вообще не понимал
ПФ
потому что это же чисто на уровне работы с сурсом — что он возвращает
OC
вот даже если на треды посмотреть, везде где пользователь что-то знает о внутренностях - например, вручную расставлять точки синхронизации - случается полный провал
ПЗ
я хочу чтобы пользователь вообще не догадывался, что его код реактивный\
Ali же в своей jvm так и сделали примерно
ПФ
твой фреймворк может знать что там на самом деле асинхронно
OC
такие вещи как happens-before
OC
на практике же никто из обычных людей даже слова такого не слышал
ПФ
такие вещи как happens-before
не должны существовать для обычного разработчика
ПФ
но с другой стороны нати софт с синхронизацией по состоянию совсем непросто
OC
в одной известной нам с тобой компании, была концепция того, что есть @Entity, которые как будто бы локальные для тебя, а на самом деле лежат в глобальной базе данных бесконечного размера, которой пользуются все приложения компании
OC
и если ты заводишь какой-то лок, то это извини сразу дистрибутед лок
ПФ
поёт 2nd-level cache
2nd-level cache…
2nd-level cache…
OC
как вспомнил, аж холодок по спине пробежал
OC
ладно сорри, переключаюсь на создание джава-дайджеста
ПФ
Ну а как — либо без многопоточности, либо так
OC
дистрибутед локи то должны быть настоящие. И процесс синхронизации, сам факт лока - это вызов по Кафке (внешняя сеть) или 0mq (внутри хоста). И дальше вопрос уже как это решится на всех уровнях - и локально внутри приложения, и на одной машине, и на кафке, и в бд, и как всё это между собой синхронизировать, и кто прав в случае проблм
ПФ
а никто кроме реляционных БД не умеет дитрибутед локи
OC
ну, мы умели