SA
как в Resource. более универсально, чем make же
Size: a a a
2020 January 01
NV
Два аргумента функции для слабых
Oℕ
как в Resource. более универсально, чем make же
Там F от тюпла
Oℕ
Там иначе не выразить
SA
да, ты прав, надо переделать
SA
как в тофу называются тайпклассы для ресурсов? я что-то сходу не нашел
Oℕ
Guarantee Finally
SA
это больше на брэкет похоже...
AS
Пора уже начинать юзать ToFu, столько вкусного...
Oℕ
это больше на брэкет похоже...
А что ты подразумевал под тайпклассом для ресурсов?
Oℕ
Для меня это и есть брэкет
λ
это больше на брэкет похоже...
Так ресурс тож брекет
SA
А что ты подразумевал под тайпклассом для ресурсов?
тайпкласс, обозначающий, что созданный эффект после вычисления надо будет еще и закрыть. а-ля Closeable в джаве.
Oℕ
тайпкласс, обозначающий, что созданный эффект после вычисления надо будет еще и закрыть. а-ля Closeable в джаве.
Ну это тип данных в скале, а не тайпкласс
Oℕ
Я не вижу, почему котоэффектный Resource плох
NV
тайпкласс, обозначающий, что созданный эффект после вычисления надо будет еще и закрыть. а-ля Closeable в джаве.
А какие гарантии это приносит?
SA
Я не вижу, почему котоэффектный Resource плох
он совмещает в себе две операции - конструирование ресурса и выполнение, через use. Я хочу их разделить
SA
Гарантии, соответственно, что код занимается конструированием, а не выполнением
SA
второй довод - композиция Resource[F, *] и F[*]. Если код написан на тайпклассах, про Resource.liftF можно забыть, всё будет унифицировано
Oℕ
второй довод - композиция Resource[F, *] и F[*]. Если код написан на тайпклассах, про Resource.liftF можно забыть, всё будет унифицировано
Я не понял этого довода