Deserializing/serializing generic objects types

[edwardcapriolo]

For the JSONRPC spec a request looks like this
jsonrpc: string
id:
method:
params? object

  class request{
  public:
    std::optional<string> jsonrpc;
    std::optional<variant<string, int>> id;
    std::optional<string> method;
  };
  NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(request, jsonrpc, id, method);

  class request_json_params : public request {
  public:
    std::optional<nlohmann::json> params;
  };

This almost works as it can be turned from object to JSON, but not json to object

      using json = nlohmann::json;
      a3a::request_json_params r;
      r.jsonrpc = "yo";
      r.id = "56";
      r.params = json::parse(R"(
        [ {"x":"y"},{"a":"b"}]
      )");
      json j = r;

      std::cout << j.dump() << std::endl;
      //auto p2 = j.template get<a3a::request_json_params>();
      //std::cout << p2.params << std::endl;
      ```
      
      The bottom two lines wont compile with a templating error. Is there a simple way to do this? Or is this the wrong approach?

[edwardcapriolo]

Example here: https://github.com/edwardcapriolo/a3a/blob/main/basic_test.cpp

[edwardcapriolo]

Thanks. My issue isn't the derived type. My issue is using json as a member property.

/home/edward/a3a/build/_deps/json-src/include/nlohmann/detail/macro_scope.hpp:402:62: error: no matching function for call to ‘nlohmann::json_abi_v3_12_0::basic_json<>::get_to(std::optional<std::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> >&) const’
  402 | #define NLOHMANN_JSON_FROM(v1) nlohmann_json_j.at(#v1).get_to(nlohmann_json_t.v1);
      |                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~

[gregmarr]

It's actually the variant that is giving you the problem. If you remove id from the NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE it compiles just fine.

[edwardcapriolo]

It's actually the variant that is giving you the problem. If you remove id from the NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE it compiles just fine.

I found this variant recipe here:
https://www.kdab.com/jsonify-with-nlohmann-json/
I realize this blog is old as the optional support is already there.

      auto p2 = j.template get<a3a::request_json_params>();
      /home/edward/a3a/build/_deps/json-src/include/nlohmann/detail/macro_scope.hpp:402:62: error: no matching function for call to ‘nlohmann::json_abi_v3_12_0::basic_json<>::get_to(std::optional<std::__cxx11::basic_string<char> >&) const’
  402 | #define NLOHMANN_JSON_FROM(v1) nlohmann_json_j.at(#v1).get_to(nlohmann_json_t.v1);
      ```
      
I guess I have two separate problems then

[gregmarr]

Here is another thread: #1261

[edwardcapriolo]

Here is another thread: #1261

I found that but I wasn't able to get it working. See my comment below:

When I use this everything works. It would be good to include this support more native to the project. Effectively there are several old and new topics on this. If the maintainers dont want to add "variant" to the library I suggest adding the most common implementation to tests somewhere to serve as a form of contract driven development.

I think that would be a nice way forward. I am someone very new to CPP, did it in college but 20 years Java :). Its hard for me to suss out all these snippets with and sort out which implementation might still work, if it cant be added to the library we can add it to a test a "contract" to say when the implementation stops working right.

NLOHMANN_JSONIFY_ALL_THINGS(request_json_params, jsonrpc, params);

This seems to work on both parent and child classes so not sure if its a better approach then two separate macros etc.

[edwardcapriolo]

Well I figured it out but I confess to being more confused :)

edwardcapriolo/a3a@f24a00b

The wiki I mentioned above provides this:

https://www.kdab.com/jsonify-with-nlohmann-json/

NLOHMANN_JSONIFY_ALL_THINGS(request_json_params, jsonrpc, params);

When I use this everything works. It would be good to include this support more native to the project. Effectively there are several old and new topics on this. If the maintainers dont want to add "variant" to the library I suggest adding the most common implementation to tests somewhere to serve as a form of contract driven development.

[edwardcapriolo]

@nlohmann @gregmarr may you please critique the approach here:

edwardcapriolo/a3a@1c88585

I borrowed the code from the all things json blog.

It supports optionals, variant, and is able to support JSON inside class objects for deeply nested data.

  void toolSerializationTest(){
    using json = nlohmann::json;
    a3a::tool t;
    t = json::parse(R"({"name": "calculate_sum",
"description": "Add two numbers together",
"inputSchema": {
"type": "object",
"properties": {
"a": { "type": "number" },
"b": { "type": "number" }
},
"required": ["a", "b"]
}
})");
    CPPUNIT_ASSERT(t.name == "calculate_sum");
    std::cout << t.inputSchema.properties << std::endl;
  }

class input_schema {
public:
  string type;
  json properties;
  vector<string> required;
};
NLOHMANN_JSONIFY_ALL_THINGS(input_schema, type, properties, required);


class tool {
public:
  string name;
  optional<string> description;
  input_schema inputSchema;
  optional<annotations_item> annotations;
};
NLOHMANN_JSONIFY_ALL_THINGS(tool, name, description, inputSchema, annotations);

Also the providef method/macro JSONIFY_ALL_THINGS seems to deal with polymorphism types without requiring two different methods. If you have some feedback may I can submit it as a PR. Its very powerful doing everything I need at this point. I dont see any flaws in it but my understanding is limited. Butif it makes sense I can prepare it for a contribution with unit tests etc.