Oℕ
Зачем забывать про лифтФ, чем ему мешают тайпклассы
Size: a a a
2020 January 01
SA
Я не понял этого довода
def a[F[_]]: F[A] = ???
def b[F[_]]: Resource[F, B] = ???
val result[F[_]]: Resource[F, C] = for { a <- Resource.liftF(a) ; b <- b } yield a + b
vs
def a[F[_]]: F[A] = ???
def b[F[_]: Disposable]: F[B] = ???
val result[F[_]: Disposable]: F[C] = for { a <- a ; b <- b } yield a + b
def b[F[_]]: Resource[F, B] = ???
val result[F[_]]: Resource[F, C] = for { a <- Resource.liftF(a) ; b <- b } yield a + b
vs
def a[F[_]]: F[A] = ???
def b[F[_]: Disposable]: F[B] = ???
val result[F[_]: Disposable]: F[C] = for { a <- a ; b <- b } yield a + b
Oℕ
def a[F[_]]: F[A] = ???
def b[F[_]]: Resource[F, B] = ???
val result[F[_]]: Resource[F, C] = for { a <- Resource.liftF(a) ; b <- b } yield a + b
vs
def a[F[_]]: F[A] = ???
def b[F[_]: Disposable]: F[B] = ???
val result[F[_]: Disposable]: F[C] = for { a <- a ; b <- b } yield a + b
def b[F[_]]: Resource[F, B] = ???
val result[F[_]]: Resource[F, C] = for { a <- Resource.liftF(a) ; b <- b } yield a + b
vs
def a[F[_]]: F[A] = ???
def b[F[_]: Disposable]: F[B] = ???
val result[F[_]: Disposable]: F[C] = for { a <- a ; b <- b } yield a + b
однозначно первое
SA
однозначно первое
потому, что?
NV
def a[F[_]]: F[A] = ???
def b[F[_]]: Resource[F, B] = ???
val result[F[_]]: Resource[F, C] = for { a <- Resource.liftF(a) ; b <- b } yield a + b
vs
def a[F[_]]: F[A] = ???
def b[F[_]: Disposable]: F[B] = ???
val result[F[_]: Disposable]: F[C] = for { a <- a ; b <- b } yield a + b
def b[F[_]]: Resource[F, B] = ???
val result[F[_]]: Resource[F, C] = for { a <- Resource.liftF(a) ; b <- b } yield a + b
vs
def a[F[_]]: F[A] = ???
def b[F[_]: Disposable]: F[B] = ???
val result[F[_]: Disposable]: F[C] = for { a <- a ; b <- b } yield a + b
Как выглядит реализация композиции двух Disposable?
SA
Как выглядит реализация композиции двух Disposable?
какой именно композиции? Монада, реализующая Disposable - это Resource
Oℕ
потому, что?
потому что ресурс - это чистая структура данных очень локально полезная
фактически никакой пользы информация о самом типе данных Resource не несёт, гораздо полезнее какими свойствами обладает F, на базе которого Resource построен
но это не столь важно, скорее стоит спросить - какова мотивация для абстракции
какие альтернативные реализации вы хотите контролировать, какое поведение постулируете
фактически никакой пользы информация о самом типе данных Resource не несёт, гораздо полезнее какими свойствами обладает F, на базе которого Resource построен
но это не столь важно, скорее стоит спросить - какова мотивация для абстракции
какие альтернативные реализации вы хотите контролировать, какое поведение постулируете
NV
А не проще пойти по другому пути через ридеры и ApplicativeAsk/HasContext?
Oℕ
Иными словами, какую проблему вы решаете, вводя такую абстракцию
SA
А не проще пойти по другому пути через ридеры и ApplicativeAsk/HasContext?
не уверен, что можно выразить ресурс через ApplicativeAsk
Oℕ
не уверен, что можно выразить ресурс через ApplicativeAsk
нельзя
SA
Иными словами, какую проблему вы решаете, вводя такую абстракцию
проблему композиции. допустим, мы пишем код инициализации приложения из 20 подмодулей. Допустим, 10 подмодулей у нас грязные, они возвращают F[A], а вторые 10 - аллоцируют системные ресурсы и возвращают Resource[F, A]. И вот их надо свести в один фор.
NV
не уверен, что можно выразить ресурс через ApplicativeAsk
Его и не нужно выражать, речь о сборе клейсли, а потом использовании в нормальном ресурсе
Oℕ
проблему композиции. допустим, мы пишем код инициализации приложения из 20 подмодулей. Допустим, 10 подмодулей у нас грязные, они возвращают F[A], а вторые 10 - аллоцируют системные ресурсы и возвращают Resource[F, A]. И вот их надо свести в один фор.
Как вы решите эту проблему, если в итоге первые 10 вернут F, а вторые 10 - G
SA
Его и не нужно выражать, речь о сборе клейсли, а потом использовании в нормальном ресурсе
не понял мысль
SA
Как вы решите эту проблему, если в итоге первые 10 вернут F, а вторые 10 - G
нет, и те, и другие вернут F, т.к. их фабричные методы выглядят как apply][F[_]: ....]: F[Module]
Oℕ
И вам всё равно нужно будет добавлять некоторый код трансформации, т.е. код не станет проще использования Resource.lift
NV
С Новым годом Сергей
SA
И вам всё равно нужно будет добавлять некоторый код трансформации, т.е. код не станет проще использования Resource.lift
? нет, нужно будет только написать инстанс Disposable для ресурса. а потом - Application[Resource[IO, *]]
Oℕ
нет, и те, и другие вернут F, т.к. их фабричные методы выглядят как apply][F[_]: ....]: F[Module]
Вы не можете получить для Resource все те же качества, которые были у F