Mapping over codecs

[kamilkloch]

What do you think about baking such an extension into jsoniter? Being able to map over codecs is quite helpful.

extension [A](underlying: JsonValueCodec[A]) {
    def imap[B](f: A => B)(g: B => A): JsonValueCodec[B] = new JsonValueCodec[B] {
      def decodeValue(in: JsonReader, default: B): B = {
        f(underlying.decodeValue(in, underlying.nullValue))
      }

      def encodeValue(x: B, out: JsonWriter): Unit = {
        underlying.encodeValue(g(x), out)
      }


      def nullValue: B = f(underlying.nullValue)
    }
  }

[plokhotnyuk]

Hi, Kamil! Thanks for the proposition!

I think the imap method could be added to JsonValueCodec and JsonKeyCodec but need to document it and mention an extra overhead of this kind of redirection that could hit performance for small values due to more dependent memory reads and virtual table calls and redundant transformation of nullValue for all cases except parsing of the JSON null value.

[kamilkloch]

Hello Andriy,

to be discussed what to do with the errors possibly occurring in f and g. Probably catch and rethrow as jsoniter error.

[plokhotnyuk]

Hello Andriy,

to be discussed what to do with the errors possibly occurring in f and g. Probably catch and rethrow as jsoniter error.

Yes, I forgot to remember this issue. That is the main reason to not include such combinators in the library.

[kamilkloch]

I understand. On the other side of the spectrum, there is ease of use for the user. Everybody could map over a BigDecimal codec to obtain a Decimal64 codec, whereas writing a Decimal64 codec by hand is out of reach for the majority:

jsoniter-scala/jsoniter-scala-macros/jvm/src/test/scala/com/github/plokhotnyuk/jsoniter_scala/macros/JsonCodecMakerDecimal64Spec.scala

Line 29 in 7875e18

implicit val codec: JsonValueCodec[Decimal64] = new JsonValueCodec[Decimal64] {

[plokhotnyuk]

I understand. On the other side of the spectrum, there is ease of use for the user. Everybody could map over a BigDecimal codec to obtain a Decimal64 codec, whereas writing a Decimal64 codec by hand is out of reach for the majority:

I have a better plan and in the next release I'm going to add support of Long representation for Decimal64 immediately to JsonReader and JsonWriter together with a field annotation @decimal64 for Long field types.

It will be safer with proper exception throwing and more efficient in runtime.

[kamilkloch]

That is great news, thank you! :) But again, this solves Decimal64 only, not an arbitrary mapping (e.g. for sttp.model.Uri).

Edit: Example use-case for a custom enum codec:

enum Type {
  case buy, sell // to be mapped to "0" and "1" over the wire
}
object Type {
  given JsonValueCodec[Type] = JsonCodecMaker.make[String]
     .map(_.ordinal.toString)(s => BuySellOrderResponse.Type.fromOrdinal(s.toInt))
}

[plokhotnyuk]

That is great news, thank you! :) But again, this solves Decimal64 only, not an arbitrary mapping (e.g. for sttp.model.Uri).

Edit: Example use-case for a custom enum codec:

enum Type {
case buy, sell // to be mapped to "0" and "1" over the wire
}
object Type {
given JsonValueCodec[Type] = JsonCodecMaker.make[String]
.map(_.ordinal.toString)(s => BuySellOrderResponse.Type.fromOrdinal(s.toInt))
}

Before that I will cut a bug fix release to allow using @named for Scala 3 enum terms. It will be much more efficient in runtime (no allocation for string, no mega-morphic virtual method calls)