Recursively nested types fail about falanx HOT 7 CLOSED

Fleece should handle recursive types without any problem when using implicit codecs (overloads) which is the case here.

This failure seems to be due to a bug that was introduced recently.

I'll have a look and see how can it be solved.

from falanx.

As single self referencing type fails:

[<CLIMutable>]
type NestedTestAllTypes =
    { mutable child : NestedTestAllTypes option }

    static member JsonObjCodec =
        fun child  -> { child = child}
        |> Fleece.Newtonsoft.withFields
        |> Fleece.Newtonsoft.jfieldOpt ("child") (fun x -> x.child) 

from falanx.

falanx_test.fs(800, 12): [FS0001] Type mismatch. Expecting a:

(IReadOnlyDictionary<string,JsonValue> -> Result<(TestAllTypes option -> NestedTestAllTypes),DecodeError>) * (NestedTestAllTypes -> IReadOnlyDictionary<string,JsonValue>) -> ConcreteCodec<KeyValuePair<string,JToken> list,KeyValuePair<string,JToken> list,NestedTestAllTypes,NestedTestAllTypes>

but given a:

SplitCodec<IReadOnlyDictionary<string,JsonValue>,(TestAllTypes option -> NestedTestAllTypes),NestedTestAllTypes> -> (IReadOnlyDictionary<string,JsonValue> -> Result<NestedTestAllTypes,DecodeError>) * (NestedTestAllTypes -> IReadOnlyDictionary<string,JsonValue>)

The type:

ConcreteCodec<KeyValuePair<string,JToken> list,KeyValuePair<string,JToken> list,NestedTestAllTypes,NestedTestAllTypes>

does not match the type:

(IReadOnlyDictionary<string,JsonValue> -> Result<NestedTestAllTypes,DecodeError>) * (NestedTestAllTypes -> IReadOnlyDictionary<string,JsonValue>)

from falanx.

@gusty The solution was to use the ConcreteCodec parts and depreciate the use of `jfieldOpt etc?

from falanx.

Yes.

To add more context: the problem is that ConcreteCodecwas introduced as the way to define codecs, while the jfield family of functions were kept as backward compatible, but this caused a problem with recursive definitions as both overloads exists and the priority is given to the ConcreteCodec.

So, an easy fix is:

• in Fleece rename the JsonObjCodec method
• in Falanx also change that to that new name

A better but more complicated fix is what you say: use in Falanx ConcreteCodec which will be the supported way moving forward.

from falanx.

Would ConcreteCodec alleviate the issue with tuple encoding?

from falanx.

Yes, ConcreteCodec does not suffer the infinite recursion, as it's the default overload.

from falanx.