as commented in the meeting <@U4UGS5FC7> <@U0RM4EP...

# arrow-contributors

[Marc]

as commented in the meeting @raulraja @simon.vergauwen @Imran/Malic @Javier here I’m sharing a gist with a snapshot of the idea

[Marc]

notice that I’m not using `sealed`fun interfaces because I’m running the code in a multiplatform project and somehow the inspector doesnt like it but the main idea is to use them together

[Javier]

context? I wasn't in the meeting hahah

[Javier]

looks like something to try to use with proofs maybe?

[Marc]

sorry I confused you then hahaha

[Marc]

I’m trying to abstract somehow a clean architecture Repository <- DataSource (called Service in this gist)

[Marc]

where a Service can represent a CRUD operation and then we would be able to implement some defaul handy implementations like a cache repository that provides a policy to retrieve data or providing some default services to store data (in this case a simple Map. The final purpose is being able to build up this in a lego-like way

[raulraja]

@Marc it looks like it’s already composable, what is it that you don’t like from it or wish it did differently?

[Marc]

something I don’t like too much is this part specificly:

[Marc]

/**
 * Mapping a put service require bidirectional mapping input -> output -> input
 */
fun <K, A, B> Service<Put<K, A>, A>.map(input: (B) -> A, output: (A) -> B): Service<Put<K, B>, B> =
    Service { (arg, value) -> invoke(Put(arg, input(value))).map(output) }

[Marc]

the fact that Put requires the type make sme imposible to do a regular mapping like others

[Marc]

because mapping Service<Put<K, A>, A> would return Service<Put<K, A>, B>

[Marc]

simple example i have in mind:

serviceA: Service<Put<String, EntityUser>, EntityUser>

//I'd like
service.map(entityToDomain) -> to be Service<Put<String, User>, User>

//but instead I have
Service<Put<String, EntityUser>, User> //that's inconsistent

[Marc]

thats why I need the two way mapping in order to make the conversion