What’s the best way to map a String to a wrapper type in Scala, where optionality is inferred from the target type?

[YannMoisan]

The context: I need to map a String to a wrapper type. The source comes from Proto3, where the optional keyword isn't used—so whether a field is optional or required is inferred from the target type.

I've written a minimal script that reproduces this behavior, but I'm wondering: is there a cleaner or more idiomatic way to achieve this?

//> using dep io.scalaland::chimney::1.8.1

import io.scalaland.chimney.{ partial, PartialTransformer, Transformer }
import io.scalaland.chimney.dsl.*

case class FromProto(a: String, b: String)
case class Wrapper(value: String)

object Wrapper {

  def from(s: String): Either[String, Wrapper] =
    if (s.isEmpty) Left("empty") else Right(Wrapper(s))

}

case class ToDomain(a: Wrapper, b: Option[Wrapper])

implicit val stringToWrapper: PartialTransformer[String, Wrapper] =
  (src: String, _: Boolean) => partial.Result.fromEitherString(Wrapper.from(src))

implicit val stringToOptWrapper: Transformer[String, Option[Wrapper]] =
  (src: String) => Wrapper.from(src).toOption

println(FromProto("", "value").transformIntoPartial[ToDomain])
// Errors(NonEmptyErrorsChain(Error(StringMessage(empty),Path(List(Accessor(a))))))

println(FromProto("value", "value").transformIntoPartial[ToDomain])
// Value(ToDomain(Wrapper(value),Some(Wrapper(value))))

println(FromProto("value", "").transformIntoPartial[ToDomain])
// Value(ToDomain(Wrapper(value),None))

[MateuszKubuszok]

I'm afraid not: most of the time I've met the requirement that validation for errors and optionality are orthogonal concepts:

• if data is invalid, fail transformation
• if it's optional but missing, make it succeed with None

Here it's contextual mixing of the two:

• if transformation fails validation, it should fail the whole transformation when it's a non-optional value
• but error should be silently discarded when it's an option.

It might be perfectly reasonable in a particular case, but it screams "extraordinary" and it has to be handled as such. In the past any "silent failures" in Chimney were reported as bugs by the community, so I believe the current approach (where one needs to define such exceptional behavior explicitly) is still desired.

At best you could use something like

implicit def relaxedTransformer[A, B](implicit pt: PartialTransformer[A, B]): Transformer[A, Option[B]] =
  (a: A) => pt.transformFailFast(a).asOption

to generate such relaxed transformation for every PartialTransformation that you define, and save a few keystrokes by defining them with

import io.scalaland.chimney.partial.syntax._ // import once and then

implicit val stringToWrapper: PartialTransformer[String, Wrapper] =
  PartialTransformer(src => Wrapper.from(src).asResult) // .asResult is available

[YannMoisan]

but error should be silently discarded when it's an option.

It’s not really an error, just an absence of value — represented as an empty string in Protobuf. That’s why I’m asking, since this seems like a fairly common scenario.

[MateuszKubuszok]

I think from PB point of view, string is a primitive which cannot have an absent value, just like integer or double. We could treat e.g. 0 as an absent value, but it's rather dangerous, more often if we needed to express absence of primitive we would wrap it in a message, or use some type mapper from PB.

If instead of a string it was Option[NonEmptyString] already generated by ScalaPB then there would be no issue, it would be transformation between:

case class FromProto(a: Option[NonEmptyString] b: Option[NonEmptyString])
case class ToDomain(a: Wrapper, b: Option[Wrapper])

the first would be option unwrapping and the second would be just a total .map on option.

I'm talking from the experience in how I saw PBs used in Scala companies. The conventions like: 0, 0.0, "" = empty, were forbidden, optional string, optional int32 etc, were required to obtain scala.Option. There was also some "untyped" bag of values that some PB definitions out there used (FieldMask), but Scala-first codebases avoided like a plague. So these issues were avoided completely at what-was-allowed-in-PB-definition level.

[YannMoisan]

indeed. Thanks a lot for your help and such a useful library !