I'm trying to port RemoteData to Koltin, any feedb...

# arrow

[Francesco megna]

I'm trying to port RemoteData to Koltin, any feedback is welcome 😄
https://gist.github.com/effe-megna/e84f5fb313daa6c5484cc07f02813bbe#file-remotedata-kt

[pakoito]

LGTM, one suggestion: remove the boolean checks isInitial, isPending etc

[pakoito]

the reasoning is that any pattern you implement with them can be done with fold

[pakoito]

if you prefer create foldX where X is each state and everything else gets a default value

[pakoito]

foldInitial(false) { true }

[pakoito]

and if someone want something that’s pending or correct, for example, fold suffices

[raulraja]

You can also just use arrow.generic.Coproduct

[Francesco megna]

the reason for the Boolean checks is the Either implementation, I follow the “standard” implementation, i absolutely prefer to use the fold

[Francesco megna]

by the way what is foldX? and any resource for the future union types in arrow? seems to be amazing news

[Francesco megna]

in the next day I will create a library with RemoteData, if anyone is interested

[raulraja]

What I ment is that you can also do :

typealias RemoteData<A, B> = Coproduct<Initial, Pending, Failure<A>, Success<B>>

[raulraja]

Since you are trying to overcome the arity of Either and that is what Coproduct does

[Francesco megna]

Ohh thanks, i will update using Coproduct

[Francesco megna]

why actual Either don’t use Coproduct?

[raulraja]

Coproduct has currently a weaker API

[raulraja]

with fold and little more

[raulraja]

and people demand Either

[raulraja]

but I hope we can remove most wrappers and nesting to follow Kotlin’s philosophy that there is no need to nest in functional style like Haskell and Scala does

[raulraja]

and for that we need union types or typelevel coproducts as a compiler plugin

[raulraja]

that would eliminate all of these but not suggesting you change your solution

[raulraja]

it looks great to me and it would make a good datatype for many users as is, just wanted to provide you more info so you can make the best design decision

[Francesco megna]

tips from community are really helpful, I’m learning fp with arrow and fp-ts, I’m in the situation when I can implement an ADT, with some error but it’s good enough in my situation. And I want to thank the community around this library, great people 😄

[Francesco megna]

do you think it can become an interesting pull request for arrow?

[raulraja]

It depends, what is the use case for this data type? I see it more as a companion libs for particular use cases like Android

[raulraja]

So maybe in arrow-android

[raulraja]

For it to be in arrow it has to be general purpose and generic and if it's an integration in an integration module

[raulraja]

We are releasing also an incubator for community libs that can be promoted to top level modules once they are mature and show usage

[raulraja]

So it can leave in the arrow org in some form but not in core or fx unless there is a strong argument for it

[Francesco megna]

I don’t think it’s specific for Android, yes probably it’s more useful for update a ui I agree in this. Actually mi implementation is not coupled to any Android module but it’s ok, i will try a pull request for discuss in a better place, thanks Raul 🙂

[raulraja]

we have other stuff like Day, More, etc in arrow-ui I believe

[raulraja]

maybe it fits there is this is the kind of stuff you use for loading state tracking

[raulraja]

those datatypes are the foundation of UIs like the ones build with Comonads

[Francesco megna]

yes in this way seems more right for me, data types for UIs, like RemoteData, arrow-ui is only in plan or it’s available?

[raulraja]

it’s available but it’s an incubating module which still has no good use for or has been promoted

[raulraja]

but once things are built with it and has a good shape it will be promoted to top level as the recursion schemes and other libs that we still plan to address from an encoding an ergonomics for the user