TransformInto Trait

[Jonathan Winandy]

👋

Is there any specific reason to not be able to transformInto a Trait ?

trait Def1 {
  def toto : Option[String]

  override def toString: String = toto.getOrElse("tata")
}

case class Def2(toto: String)

object TestChimney {
  import io.scalaland.chimney.dsl._
  
  def main(args: Array[String]): Unit = {
    val def2 = Def2("toto")
    println(def2.transformInto[Def1])
  }
}

Chimney can't derive transformation from Def2 to Def1

Def1
  derivation from def2: Def1 is not supported in Chimney!

Consult https://chimney.readthedocs.io for usage examples.

  println(def2.transformInto[Def1])

Use case

Sometimes common data models are defined as traits, turning into one can help to manage differences in required fields.

Work around

//just create a case class for the trait
case class Def1Container(toto : Option[String]) extends Def1

[Mateusz Kubuszok]

Yes: there is no non-controversial way to do it. trait and abstract class have no normal (non-abstract) constructors, that were defined with the intent to construct a fully initialized object. To instantiate trait we would have to:

• create an anonymous class
• find all abstract members of it
• check if their visibility would even allow us to implement them
• basically guess what would be their implementations
• put the implementations in the anonymous class, hoping that there are no assert or other runtime surprises
• if all abstract members would be vals or nullary defs, perhaps that would be doable
• if there would be any def which takes arguments, we would be pulling implementations out of thin air

So, it would be:

• rather hard to implement
• only possible for some special cases, which isn't very predictable
• feel even more magical, while one of the things we have to fight, is the argument that nobody understands where the transformation comes from and so it cannot be trusted
• quite error prone.

Perhaps if #192 would be implemented, than you could provide a function constructing such trait yourself and it would be non-ambiguous how it works. With features we have now we do not add support for case which would give users more troubles than benefits.

Of course the above is only about "open" traits. sealed traits are supported and any sane data model uses traits only as sealed traits, leaving non-sealed for interfaces, services, etc.

[Jonathan Winandy]

Thank you so much for explaining it.

And it's easy to go around, we can create a case class that extends the trait.

case class Def1Container(toto : Option[String]) extends Def1