Inheriting a Transformer from a supertype

[nrinaudo]

I'm currently working on a project that's rather convoluted and involves quite deeply nested subtyping hierarchies. So for example, I might have to work with types A1, B1 and C1 such that B1 and C1 are both subtypes of A1. I need to transform them into A2, B2 and C2 with the same subtyping relationships.

None of the transformers can be fully derived - I may have, for example, to rename A1.a1 to A2.a2, as well as some further bespoke transformations in the Bs and Cs.

In my current implementation, I need to do the a1 -> a2 renaming in both Transformer[B1, B2] and Transformer[C1, C2], which may not seem like a big deal, but I actually have 7 or 8 properties to rename, and I have subtypes B to Z. That's starting to be around 200 lines of duplicated code, which I'd really rather avoid.

Is there a way of factorizing that? Of declaring that all subtypes of Transformer[A1, A2] will do the a1 -> a2 rename, plus whatever else they need to do?

[MateuszKubuszok]

I haven't tried tackling such case, but there is one thing that might potentially help handling it:

val transformationInProcess = foo.into[Bar]
  .withFieldRenamed(_.a1, _.a2)

transformationInProcess
  .withFieldConst(_.a2, value)
  .transform

transformationInProcess
  .withFieldComputed(_.a2, foo => ...)
  .transform

The chaining, at the same time:

• computes some phantom types that carry information how we are customizing transformation
• appends values ("consts" and "computed") in the runtime to some Vector

so splitting the transformation into parts is possible, as long as the type-level config is preserved.

I guess such a refactoring as what you think about might be more tricky, but I believe something like:

// Example with Transformer here because you probably want to reuse
// but works with inlined transformations as well

// Let the type be inferred
def sharedFields[Str <: A1, Tgt <: A2] = Transformer.define[Src, Tgt]
  .withFieldRenamed(_.a1, _.a2)

import io.scalaland.chimney.internal.runtime.{
  TransformerFlags,
  TransformerOverrides,
}

def specializedForB[Overrides <: TransformerOverrides, Flags <: TransformerFlags](
  shared: TransformerDefinition[B1, B2, Overrides, Flags]
) = shared
  .withFieldRenamed(_.b1, _.b2)

sharedFields[B1, B2]
  .pipe(specializedForB)
  // maybe some more overrides
  .buildTransformer

should do the trick.

If def needs to have some signature - more likely Scala 3 case? - then you can use transparent inline def to define it as TransformerDefinition[Src, Tgt, ? <: TransformerOverrides, ? <: TransformerFlags], at call site it will become a full type.

DSL only needs to know type enough to see that there is val/nullary def to call. Only when it reaches .transform/.buildTransformer this config is validated against the types. If at that moment the whole type is known, and there is enough information in the phantom type to fill the gaps it should compile.

[nrinaudo]

I'll play with it a little more, try to refine it, but the "in process" pattern was just confirmed to work just fine. It's not the direction I was looking into, but it's definitely a good answer, thank you!

I'm not entirely sure what the specializedForB bit is for, though. It seems to work just fine if I do:

sharedFields1[B1, B2]
  .withFieldRenamed(_.b1, _.b2)
  .buildTransformer

Am I missing something subtle?

[MateuszKubuszok]

Not really, if you can always tell in the specialized part to which config chain you are appending, then you can just use a value. Just that in general you could create a bunch of:

transparent inline def handleA(...) = ...
transparent inline def handleB(...) = ...
transparent inline def handleC(...) = ...

and then:

Transformer.define[Src, Tgt]
  .pipe(handleA(_))
  .pipe(handleC(_))
  .pipe(handleE(_))
  // ...
  .buildTransformer

if e.g. these renames were not strict subsets of one another, because some intersection type was at play then you'd have to be able to reuse some independent sets of overrides.

But if it's strictly hierarchical and you can always point out the previous val/def with shared part then such generalization is not needed. 🙂

[nrinaudo]

Oh I see! yes, that makes a lot of sense. My scenario is strictly hierarchical, which is why I was confused. Thanks!