Make Tool and Function classes easier to deserialize

[endeffects]

Currently it is not possible to deserialize the Tool and Function classes by using System.Text.json.
My goal here is to load the tools / functions at runtime to enable / disable them on my need without creating a new release i.e.

I also have some other related points here:

1. It would be nice to have a more type safe implementation for the Function class that does not require json types.
2. It also would be nice not to have sealed classes here, to build additional forward logic on the openAi callback.
3. An alternative approach to keep the sealed classes would be the possiblity to declare a deserialisation type for the function arguments.

With that option it would be possible to dynamically deserialize the callback without any switches and pass it to some other processing handlers:

        // Processing Function Callback from OpenAi
        
        if (source.FirstChoice.FinishReason != "tool_calls") return result;
        if (source.FirstChoice.Message?.ToolCalls == null) return result;
        
        foreach (var tool in source.FirstChoice.Message.ToolCalls)
        {
            var arguments = $"{tool.Function.Arguments}";
            
            // At the moment i have to use an additional Dictionary to get the correct Deserialization Type
            // In my case i'm deserializing the function arguments into types that are implementing IRequest<TResult> of the MediatR nuget package
            if (JsonSerializer.Deserialize(arguments, this.tools[tool.Function.Name].Type) is not IRequest<MessageModel> request) continue;

            // So the better approach would be something like:
            // if (JsonSerializer.Deserialize(arguments, tool.Function.ArgumentsType) is not IRequest<MessageModel> request) continue;

            // Then i can pass the request to the mediator that calls the required handler to process the function callback
            var result = await this.mediator.Send(request, cancellationToken);
        }

[StephenHodgson]

You're going to have to give a better explanation of your desired use case.

Also please consider to use a more type safe implementation here and get rid of the json types.

The goal here is to let you unpack the objects as you need them. You should be able to deserialize any data you need already, since it is json, which means it is inherently serializable.

[ADefWebserver]

@endeffects Can we get an example?

[endeffects]

i have updated my post and provided some more details and samples

[endeffects]

Here is a non working example on net core 8.0.

var options = new JsonSerializerOptions { PropertyNameCaseInsensitive = false };        
using var stream = File.OpenRead("functions.json");        
var tools = JsonSerializer.DeserializeAsync<List<Tool>>(stream, options);

[
  {
    "Function": {
      "Name": "FindSomething",
      "Description": "Find something",
      "Parameters": {
        "Type": "object",
        "Properties": {
          "Query": {
            "Type": "string",
            "Description": "The query"
          }
        },
        "Required": [ "query" ]
      }
    }
  }
]

[endeffects]

Just to be clear here, we are discussing two different things in parallel right now.

1. i want to be able to deserialize the tool and function classes

And unrelated to this one:

2. I want to define a deserializion type somewhere for the function arguments

[StephenHodgson]

All my unit tests are based off of deserializing the JSON string 😂

[StephenHodgson]

1. Is already possible
2. Is something I've been wanting to tackle but haven't had the time to get around to it

[StephenHodgson]

I guess I'll need a more concrete example of what exactly your use case is, because I still don't quite understand what the problem is for 1.

[endeffects]

i've checked that deserialization issue again and it was my fault. you are using JsonPropertyName attributes that are enforcing a case sensitivity over the PropertyNameCaseInsensitive setting on the serializer options. in my sample json the property names were title case, so the values got ignored.

[ADefWebserver]

Well, if openAi brakes something here everyone who uses callbacks has to fix it anyways, type safe or not. So I'm not sure if it is an argument.

Ok I see your point. So is the request now this?:

3. An alternative approach to keep the sealed classes would be the possibility to declare a deserialization type for the function arguments.

[endeffects]

Yes, this would allow us to use an implicit deserialisation instead of an explicit one for the argument types.

[StephenHodgson]

I considered adding an abstract base tool class or interface for exactly this reason.

Unsure which would be the better solution in this case but the polymorphic nature of some of the function calls made that a bit harder to do in practice.

[endeffects]

Maybe an alternative would be a generic function class that inherits from the existing one and can be passed to the tool class.

In that way all your existing code would stay as it is and I can keep my inheriting collection of tools.

public class Function<TArgs> : Function { public TArgs Type { get; } }

Maybe an Interface to upcast and access the type property is required too.

[StephenHodgson]

Draft PR #241