Derivation of by-types and Tuple* transformers

[coffius]

Hi, chimney people.
I have two questions in regard of the library:

• Is it possible now to make field resolution only by types?
• Is it possible to convert two or more objects into a new one?

In the first case I can imagine something like that:

final case class A(fieldB: B, fieldC: C)
final case class AA(b: B, c: C)
A(a, b)
  .into[AA]
  .enableCoolTypeResolution // <==
  .transform

I've seen examples of using withFieldRenamed for such cases but it would be great to have an automatic way of transforming such objects.

For the second question:

final case class FirstPart(a: A, b: B)
final case class SecondPart(c: C, d: D)
final case class Result(a: A, b: B, c: C, d: D)

val first = FirstPart(a, b)
val second = SecondPart(c, d)
(first, second) // Tuple2[FirstPart, SecondPart]
  .into[AA]
  .enableCoolTupleMagic // <==
  .transform

I know it is possible to define transformers manually for both cases but I wonder maybe there is a way to automate transformer derivation somehow for these examples.

Thanks in advance 😊

[MateuszKubuszok]

Hello, sorry for the late answer but I had a busy week.

1. if either source or target is a tuple, Chimney always match fields by their positions in the constructor (_1 to _1 or _1 to the first constructor's argument, or the first argument in a case class constructor to _1, etc), otherwise it always match fields and constructor arguments by their names
   • matching by-type-only would hardly ever be possible since most of the time you have mappings from/to e.g. (String, String, String) where there would be more ambiguities to manually resolve than automatically resolved values (kinda defeats the purpose of automation). This basically assumes that both source and target type are different orderings of the same non-repeating types
   • I am not opposed though to allowing such behavior with a flag, however I need to say that I would not have a capacity to implement such feature anytime soon
2. there is a pending ticket for that, but in general it is more complicated that it sounds, since Chimney derivation is recursive and we would have to merge these 2 objects recursively. I have an idea how to do it, but it is several-week long effort, recently I have very little time, and currently there is a few more pending tasks to do in order to release 0.8.0 final.