Add DeferredKMonadThrow #1231
Add DeferredKMonadThrow #1231
Conversation
| @@ -71,6 +71,9 @@ interface DeferredKMonadError: MonadError<ForDeferredK, Throwable>, DeferredKMon | |||
| deferredHandleErrorWith { f(it).fix() } | |||
| } | |||
|
|
|||
| @extension | |||
| interface DeferredKMonadThrow: MonadThrow<ForDeferredK>, DeferredKMonadError | |||
|
|
|||
| @extension | |||
| interface DeferredKBracket: Bracket<ForDeferredK, Throwable>, DeferredKMonadError { | |||
There was a problem hiding this comment.
interface DeferredKBracket: Bracket<ForDeferredK, Throwable>, DeferredKMonadThrow {
There was a problem hiding this comment.
Or maybe this goes in MonadDefer. Please check the other implementations :D
There was a problem hiding this comment.
thinks poiting out, and fixing and check other impl.
DeferredKMonadDeferred already used DeferredKBracket, so I fixed DeferredKBracket using DeferredKMonadThrow.
(compare to io.kt and singlek.kt)
There was a problem hiding this comment.
by the way, I have some question.
-
DeferredKAsync#invoke is deprecated,
so can I deleted it in this PR? or make other PR? -
Which do you prefer implementation io.kt or singlek.kt (or else) ? (when I implement it)
- In case of Bracket, singlek (and other rx ext) override only bracketCase, on the other hand, io override bracketCase, bracket, guaranteea and guaranteeCase. (I can't choose it...)
- In case of MonadError, io impl applicative method, other side singlek impl applicative-error method. ( I like singlek's ver ^_^ )
(Please excuse my poor English and these question are little related this PR.)
There was a problem hiding this comment.
For the typeclasses, the derived functions are often less optimal than a concrete version. And thus if a data type has a concrete impl is available, it's always beneficial to override it.
The only important thing is that laws don't break, which is checked by tests (laws).
MonadThrow sits between MonadError and Bracket so that look goods!
There was a problem hiding this comment.
About deprecating DeferredKAsync#invoke I am fine with removing it, but it's probably best to keep that for another PR. That way you'll also have the joy of closing and contributing 2 PRs ;)
About your second questions.
It seems that the SingleK instance is incorrect, since MonadError should be a valid instance for both Monad and ApplicativeError. Which is not the case for SingleK.
interface SingleKMonadError : MonadError<ForSingleK, Throwable>, SingleKMonad
As you can see it does not implement ApplicativeError<ForSingleK, Throwable> (SingleKApplicativeErrorInstance).
This is the reason SingleK implements the applicative-error methods here.
The reason io (re)implements applicative methods is because they're both implemented by Monad & ApplicativeError and thus need to explitely redefine it to avoid the diamond problem
No description provided.