Transformation failure when a case class has a method starting with set

[ghostdogpr]

Checklist

• I read the documentation at https://chimney.readthedocs.io/ and checked that the functionality exists
• I verified that the behavior for my use case doesn't match the documentation
• I checked the https://github.com/scalalandio/chimney/issues and haven't found the issue reported
• I confirmed that the bug is not related to functionality that was deprecated: lifted transformers (TransformerFs) or unsafeOption flags

Describe the bug
Given 2 case classes A and B that have the same content, if A has a method starting with set, B can't be converted to A.

Reproduction

import io.scalaland.chimney.dsl._

case class A(values: List[Int]) {
  def setValue(value: Int): A = A(List(value))
}
case class B(values: List[Int])

A(Nil).transformInto[B]
B(Nil).transformInto[A]

Scastie: https://scastie.scala-lang.org/ke3lsriNTSG6AOMivpvODQ

Expected behavior
Transformation should work.

Actual behavior
Transformation fails with:

Chimney can't derive transformation from Playground.B to Playground.A

Playground.A
  setValue(value: scala.Int) - no accessor named value in source type Playground.B


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

Which Chimney version do you use
Version you used for confirming bug with a snippet.

Which platform do you use

• JVM
• Scala.js
• Scala Native

If you checked JVM
JDK17

Additional context
Appeared in 0.8.0, working well in 0.7.x.

[MateuszKubuszok]

Every method starting with set is considered a setter, to write to setters there has to be a flag enabled (.enableBeanSetters). Ignoring setters is currently not supported.

In 0.7.x we also checked if return type is Unit to consider something a setter, but it was removed to allow targeting mutable builders with fluent API and Unit is no longer listed as a requirement in the docs.

[ghostdogpr]

It would be nice if those set methods were ignored unless enableBeanSetters is true. I had to rename a few fields (that were not returning Unit) to work around it, nothing serious though 😄

[MateuszKubuszok]

I'd say I cannot do this: virtually every single time we "let something work out of the box, with opt-out option" we soon received a ticket that this is unsafe, results in unpredicatable code, and the default should be an error with an explicit resolution, otherwise the library is dangerous to use -_-". Examples OTOH:

• when we used default values as fallbacks, we got a ticket that this is unsafe - at first the ticket to allow disabling them Option to require explicit field discarding #53 and then a ticket to make it opt-in Control over default configurations of transformers #176 (comment)
• when we added the ability to read from defs, we were quickly requested to disable it by default Don't use fields or methods by default? #128
• when we created PartialTransformer we created it with a seamless decoding of Protobufs in mind (e.g. safe unwrapping of Options) - soon we got Create feature flag for enabling expandPartialFromOptionToNonOption #322 which asks for both the flag as well as making it disabled by default
• and for a long time we had a ticket for disabling autoderivation - Ability to not use auto-derivation #166

Additionally, I remember some requests on Gitter, when we still used it, for disabling automatic wrapping/unwrapping of AnyVals.

When Java Bean getters were initially implemented they were opt-out - #81 - but then we changed it to opt-in in c71a429 because of #85.

So all in all, we converge towards disabling features by defaul based on the feedback from the community. If I enable something OOTB, I can start the timer till the mob with torches arrives.

I see 2 things that could be done to address your issue:

1. workaround for now would be to use implicit TransformerConfiguration to share enableBeanSetters and maybe something like withFieldConst(_.getField, null), this would require having getter though and produce an useless call with an overhead.

   import io.scalaland.chimney.dsl._
   
   implicit val cfg = TransformerConfiguration.default.enableBeanSetters
   
   case class A(values: List[Int]) {
     def getValue: Int = 0 // stub for matching only
     def setValue(value: Int): A = A(List(value))
   }
   case class B(values: List[Int])
   
   B(Nil).into[A].withFieldConst(_.getValue, 0).transform

   If there would be no stub getter, to provide a value, nor other source field to read from with matching name, it would not work

2. a proper solution could be adding a flag like .enableIgnoreUnmatchedBeanSetters allowing to ignore such unmatched setters, then you could enable it in your whole scope via implicit, it would look something like:

   import io.scalaland.chimney.dsl._
   
   implicit val cfg = TransformerConfiguration.default.enableIgnoreUnmatchedBeanSetters
   
   case class A(values: List[Int]) {
     def setValue(value: Int): A = A(List(value))
   }
   case class B(values: List[Int])
   
   A(Nil).transformInto[B]
   B(Nil).transformInto[A]

[MateuszKubuszok]

I released 0.8.3 with enableIgnoreUnmatchedBeanSetters flag which should make it easier to deal with your cases.

[ghostdogpr]

Thanks!

[MateuszKubuszok]

I am considering adding in 1.0.0-RC a flag to switch between 0.7.x and 0.8.x behavior, no ETA ATM.

[MateuszKubuszok]

NoUnitBeanSetters flag added in 1.0.0-M4