Size: a a a

Scala User Group

2020 July 23

λ

λoλzod in Scala User Group
еще один пример (плохой пример, но хороший для сравнения с List):

тип : Future[User]
unit : Future{ service.syncGetUser() }
join : Future(id).flatMap(id => service.syncGetUser(id)) (очень натянутый пример уплощения)

Всё что имеет эти три элемента можно засунуть в for() .
источник

GD

Gleb Donets in Scala User Group
О, и еще момент: flatMap определяется же набором правил, которым эта функция должна следовать?
источник

GD

Gleb Donets in Scala User Group
Бо очень много о ней пишут и очень много обращают внимание, хотя то, что она _должна_  делать довольно очевидно
источник

GD

Gleb Donets in Scala User Group
Я не знаю, может, конечно, это мне после LINQ в дотнете это очевидным кажется, но все же
источник

GD

Gleb Donets in Scala User Group
Или я чего упускаю
источник

λ

λoλzod in Scala User Group
да, но на самом деле есть одна неочевидность, как видно монады могут иметь очень разную природу
в случае с Future моделируется последовательные асинхронные вычисления а в случае с List моделируется неопределённость значения (у вас не одно значение а целый список).
и это очень разные по природе монады, и flatMap у них делает совершенно разные вещи
источник

GD

Gleb Donets in Scala User Group
λoλzod
грубо монада это такая структура, состоящая из тройки

типа монады: F
unit: A => F[A]
join: F[F[A]] => F[A]

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

пример монады:

тип : List
unit : List(1)
join: List::flatten
Сохраню-ка я себе это на всякий случай
источник

AD

Apache DOG™ in Scala User Group
Gleb Donets
Сохраню-ка я себе это на всякий случай
Да это написано на каждом ФП-заборе
источник

AD

Apache DOG™ in Scala User Group
Статей что такое монады больше чем всех остальных
источник

λ

λoλzod in Scala User Group
их объединяет только общая структура (вышеописанная)
источник

GD

Gleb Donets in Scala User Group
λoλzod
да, но на самом деле есть одна неочевидность, как видно монады могут иметь очень разную природу
в случае с Future моделируется последовательные асинхронные вычисления а в случае с List моделируется неопределённость значения (у вас не одно значение а целый список).
и это очень разные по природе монады, и flatMap у них делает совершенно разные вещи
ну, в деталях - да, в общем - нет
источник

λ

λoλzod in Scala User Group
(ну и мелким шрифтом надо написать что Future не монада в математическом смысле, так как не выполняются определённые требования)
источник

GD

Gleb Donets in Scala User Group
Apache DOG™
Статей что такое монады больше чем всех остальных
Так-то да, но чем больше - тем лучше. Некоторые вещи должны отложиться в голове и стать очевидными с практикой и временем, чтобы ты не тратил время на их переизобретение каждый раз, а ими думал
источник

GD

Gleb Donets in Scala User Group
λoλzod
(ну и мелким шрифтом надо написать что Future не монада в математическом смысле, так как не выполняются определённые требования)
Я не очень люблю думать о Future с точки зрения ФП, ибо под капотом там все то же родное ООП
источник

AD

Apache DOG™ in Scala User Group
Да всюду во всех монадках для конкарренси внутри грязный код
источник

YR

Yau Ref in Scala User Group
Тред как водится не читал, так что может не в тему, но вкину, что есть замечательный better-monadic-for нормальный работы со всякими IO, Тасками и имплиситами в for'е
источник

GD

Gleb Donets in Scala User Group
То, что на него натянули интерфейс, позволяющий это встроить в ФП - это хорошо, но я опасаюсь о нем думать без вспоминания о единице работы, тред пулле и всего такого
источник

GD

Gleb Donets in Scala User Group
И мерзопакостнейшего механизма ожидания, господи, как же отвратительно сделали, ну зачем же так, ну
источник

GD

Gleb Donets in Scala User Group
Ну это личный бугурт
источник

GD

Gleb Donets in Scala User Group
Apache DOG™
Да всюду во всех монадках для конкарренси внутри грязный код
Ну, ожидаемо. История примерно как с реляционными БД
источник