Make it easier to compose ConcreteCodecs

[Choc13]

Currently jreqWith etc require that the codec passed to them is a "pair of functions" type codec. Such as (JsonValue -> a' ParseResult) * (a' -> JsonValue). However, when defining codecs for more complex types it's preferable to use the applicative style which creates a ConcreteCodec. It's then cumbersome to use this codec in another codec as it requires converting back to "pair of functions" type by doing codec |> Codec.ofConcrete |> Codec.compose jsonObjToValueCodec.

As an example consider the following types:

type Foo = { X: int }

type Bar = { Foo: Foo }

Then you might want to define codecs for them in another module which currently requires writing them like this:

module Foo =
    let codec =
        fun x -> { X = x }
        <!> jreq "x" (fun x -> x.X)

module Bar =
    let codec =
        fun foo -> { Foo = foo }
        <!> jreqWith (Foo.codec |> Codec.ofConcrete |> Codec.compose jsonObjToValueCodec) "foo" (fun x -> x.Foo)

So it would be nicer if we could avoid having to convert between the two codec representations.

[gusty]

I think a good solution should be to duplicate all those functions for both modules / types.

This means in your example you should be able to do directly ConcreteCodec.compose.

Maybe we should come up with a better / shorter alias for ConcreteCodec, specially considering we'll be encouraging it use over the pair of functions.

[Choc13]

Yes I think renaming ConcreteCodec might a good idea. It seems to me that ConcreteCodec is actually a codec specifically for a JObject only, whereas the more general Codec type works for any JValue which might include JObject. Is that correct?

If so then how about naming it ObjectCodec?

[gusty]

... whereas the more general Codec type works for any JValue which might include JObject. Is that correct?

No, actually they are both very generic, the main difference being that ConcreteCodec is a type with associated operations, whereas the tupled functions are just tupled functions so they don't carry codec operations nor intention.

[Choc13]

Hmm ok, I think my confusion came about when working with them and trying to convert between concrete and pair of functions using Codec.ofConcrete and Codec.toConcrete. As it seems like it's possible to take JsonObjCodec and call Codec.ofConcrete on it which gives you back a pair of functions between IReadOnlyDictionary and JsonValue, but it wasn't possible to say write JsonCodec.string |> Codec.toConcrete.

Also when I was trying to write jfromWith (as shown in #103) it only made sense to define this on JsonObjCodec as it doesn't make sense to "lift" a simple value into a JSON object, because it would need to be nested under some key.

[gusty]

Yes, we need to provide codecs like JsonCodec.string as ConcreteCodec as well, possibly under a different module.

I'll think what's the best way to accomplish this.