Compilation of partial transformation fails when there are fields named both is{Name} and {name}

[doohochang]

Describe the bug
Compilation of partial transformation fails when the destination type contains fields named both is{Name} and {name},

Compilation succeeds when adding .withFieldComputed(_.isName, _.isName), but fails with .withFieldRenamed(_.isName, _.isName) or without it.

Reproduction
Scastie Code Snippet

Code

import io.scalaland.chimney.dsl.*

case class Proto(isSomething: Boolean, somethingDetail: Option[Proto.SomethingDetail])
object Proto:
  case class SomethingDetail(a: String, b: Int)

case class Domain(isSomething: Boolean, something: Option[Domain.Something])
object Domain:
  case class Something(a: String, b: Int)

val proto = Proto(isSomething = true, somethingDetail = Some(Proto.SomethingDetail("hello", 1)))

val result = proto.intoPartial[Domain]
  .withFieldRenamed(_.somethingDetail, _.something)
  .transform

println(result)

Error

Chimney can't derive transformation from Playground.Proto to Playground.Domain

Playground.Domain
  isSomething: scala.Boolean - can't derive transformation from isSomething: scala.Option[Playground.Proto.SomethingDetail] in source type Playground.Proto


scala.Boolean
  derivation from somethingdetail: Playground.Proto.SomethingDetail to scala.Boolean is not supported in Chimney!


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

Which Chimney version do you use
0.8.4

Which platform do you use
Scala 3.3.0, 3.3.1, 3.3.2-RC1 / JVM

[MateuszKubuszok]

This behavior is not that surprising:

• every type with a constructor is suspected to be POJO, which might or might not have getters and setters and where getters and setters with Bean naming convention does not have to be only allowed methods on the object
• every nullary method defined on the object that starts with get or is (is require additionally the method to return Boolean) is considered to be a getter
• every unary method defined on the object that starts with set is considered to be a setter
• the above is not something we wish to change as it help us NOT use mutating operations unless users explicitly request that AND report that the transformation failed because there might be a getter/setter that was not user but could be (simply disabling that logic would break the existing behavior)
• field/constructor argument overrides (withField* methods) allow setters to be overridden using a matching getter e.g. to override setValue one can write withFieldConst(_.getValue, value)
• code assumes that nobody has at once 2 different sources matching the same name e.g. getName and name which would be used as a source for a constructor's argument name or a setName setterm so it uses the first matching found
• in your example when isSomething: Boolean is looking for a matching the definition with something: Option[Something] appears before isSomething: Boolean
• rename just pretends that there is a different target field name, but the logic is basically the same, it finds the first matching name

A case where there is multiple sources that match the same name but which have different types is rather unusual, hardly everyone would find such issue so it's a low priority. If any one wanted to work on it I am open to PRs but I don't have a capacity to work on this.

[MateuszKubuszok]

Fixed in 1.0.0-M4