Closed Marius9595 closed 3 days ago
Hi @Wolfremium13!
Thanks for your proposal! :D
The approach is interesting. To keep something like the pipeline of transformations you propose is something that we want to.
The usage of Future
sounds good because we could avoid the duplication of monads such as Either
with EitherAsync
. Although I am a little concerning about some method names:
toAsync
instead of toPromise
. I would maximize the essential instead of the implementation detail.complete
is something distinct to Either Context, probably it makes sense because we are dealing in this case with async stuff. But it is personal feeling because I would like something that keeps the match contract, but I think without duplication is not possible.What do you think @myugen? This proposal allows creating a pipeline of transformation with sync and async stuff, for me the main requirement.
Hello, how's it going? I was thinking about trying to support the interoperability of
Either
functions, which are synchronous, withFuture
functions. For this, I was inspired by the.toAsync
method fromLanguageExt.Core
, which allows converting anEither
into one that supports asynchrony. In our case, we have theFuture
component. Here's an example case:Where in abstract class we add:
And in its implementations:
I'm no expert in this field, but I find it interesting to be able to chain synchrony with asynchrony, giving the latter the possibility to have previous asynchronous calls. Let me know if you have any feedback.