Open lihaoyi opened 1 year ago
I just got this issue where I wanted to keep compatibility with other serializer that serializes nested object types as Something$Inner
, so I override the method objectTypeKeyReadMap
to replace .
with $
, but it didn't help, is this related to this issue?
Currently, if you define a new
upickle.Api
with e.g. differenttagName
orobjectTypeKeyReadMap
, you immediately lose the ability to use theupickle.default.ReadWriters
defined by other people. This doesn't make sense, since by overriding those things you just want a custom runtime config and often don't want incompatible types at allThat is a consequence of us tying both custom-readwriters and runtime-configuration to the same
upickle.foo
object. The former needs to be there for implicit resolution of custom readwriters to work without imports (one of the goals of com-lihaoyi), while the latter is not really necessary.in theory we could break them apart into two separate things that people can define and configure, or if we gave up on the "works without imports" thing we could just have a single object for runtime configuration and the implicits can live anywhere (but then you need to be careful with imports if you want to override something)
we could also have some kind of way of defining a new
upickle.foo
that lets you define runtime config but uses existing types e.g.upickle.default.{Reader,Writer,ReadWriter}
. That could give us a new option to share the types but with a custom runtime config