Feature request: Support pluggable, map-like models about chimney HOT 4 CLOSED

I am not sure what is the actual use case here.

If it's only about serialization, then there is a plenty libraries that do exactly that e.g. Circe. Because functions are composable, you could use Circe generic/derivation to create Encoders/Decoders. If there is a mismatch between JSON and case class format then optics can solve that.

If it's not about serialization. but some generic structure I am still not sure what would be benefit of using chimney here. Configuration of a custom behavior could require so much code, that writing shapeless by hand could be faster (or maybe magnolia). The main driving force behind chimney is that both input and output format are known at compile time and the transformation cannot fail.

from chimney.

The use case is indeed serialization. What's different about Chimney vs Circe (AFAICT) is that to my eyes, Chimney looks like an object mapper whereas Circe looks like a serializer.

With Chimney you're describing how the fields between two types match each other (ex: .withFieldRenamed(_.addict, _.forAddict)) using actual field references (which are refactoring safe) without having to explicitly construct the destination object and pass in the fields, and that's awesome. This also means that in theory you could use the same mappings bi-directionally, as some object mappers do.

Of course Chimney mappings currently appear to be defined per object instance (ex: command.into[CoffeeMade]) rather than per type (ex: Chimney.mapperFor[Command, CoffeeMade], but I assume per type should be possible. This alone would be a nice enhancement to Chimney, where the same mappings could be used on multiple instances of some type.

You're right though that as far as mapping to map-like structures goes, you can't guarantee that the types will match for each field in the map, but that's a general deserialization problem.

from chimney.

Regarding mapping between types, you can always define implicit Transformer[A, B] which you can tune as you want. Then such transformer is picked from implicit scope by the macro each time we require transformation from A to B (including nested types). I can't see urgent reason to provide extra syntax for it.

What you originally suggested was not exactly mapping (transforming) task, but (de)serialization from map-like structures which are known not to be strongly typed, thus you have to deal with error handling (missing fields, wrong types, etc.). This is not in scope of Chimney library.

Instead, for such use case I would suggest either to:

• define serialization type class and use type class derivation (shapeless, magnolia or own macro) to save you from writing mappings manually, but to generate it following some naming convention
• use any existing library that handles this task already pretty good (above mention circe, play-json, or many others)

from chimney.

A custom Transformer doesn't save me from having to write a bunch of boilerplate for all my serializations, twice (one for each direction). I suspect that Circe and others can't be adapted to what I'm trying to achieve since they don't capture field references like Chimney does, but this idea not being within the scope of Chimney is fair enough. Thanks for the response.

from chimney.