Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use the same interface for writing arrays and non-arrays #1283

Closed
acki-m opened this issue Oct 7, 2018 · 4 comments
Closed

use the same interface for writing arrays and non-arrays #1283

acki-m opened this issue Oct 7, 2018 · 4 comments
Labels
state: please discuss please discuss the issue or vote for your favorite option

Comments

@acki-m
Copy link

acki-m commented Oct 7, 2018

Hi Nils,

Is it possible to add a state based serialization interface, where I can use the same interface of writing values independent whether it is an array or a normal json based value?
The current problem I have is a code duplication because of the current interface:

bool write_atomic_types_to_json(nlohmann::json& j, std::string name, const variant& var, const type& t)
{
    if (t.is_arithmetic())
    {
        if (t == type::get<bool>())
            j[name] = var.to_bool();
        else if (t == type::get<char>())
            j[name] = var.to_bool();
        else if (t == type::get<int8_t>())
            j[name] = var.to_int8();
        else if (t == type::get<int16_t>())
            j[name] = var.to_int16();
        //.... more code to follow

        return true;
    }

When I do now the same for an array, I cannot reuse the code from above, I have to use push_back, to insert the values.

bool write_atomic_types_to_json_array(nlohmann::json& j, const variant& var, const type& t)
{
    if (t.is_arithmetic())
    {
        if (t == type::get<bool>())
            j.push_back(var.to_bool());
        else if (t == type::get<char>())
            j.push_back(var.to_bool());
        else if (t == type::get<int8_t>())
            j.push_back(var.to_int8());
        else if (t == type::get<int16_t>())
            j.push_back(var.to_int16());
        //... more code to follow

        return true;
    }

There are two different interfaces for writing a value in JSON, this is okay. But for my use case
it would be nice to have something like this:

writer.StartObject();
    writer.String("Foo");
    writer.Int(42);

    writer.String("MyArray");
    writer.StartArray();
        writer.Int(1);
        writer.Int(2);
        writer.Int(3);
    writer.EndArray();
writer.EndObject();

Will result in following:

{
    "Foo" : 42,
    "MyArray" : [1, 2, 3]
}

That code snippet is actually from rapid-json.

You see the writing of key and the value doesn't distinguish between an array or a normal key-value based json object. I can reuse the same writing routines. Does this make sense?
I am new to your library, maybe there is a workaround to get what I need with the current interface.

@nlohmann
Copy link
Owner

nlohmann commented Oct 7, 2018

I understand your point, and there is already quite similar code in the SAX-DOM parser, see https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/json_sax.hpp#L282. You basically need to have a similar handle_value function and keep a stack inside to know whether to forward the value to an array or an object. Basically, the implementation should be able to use the public API.

I am not sure whether your required functions are of general interest. Therefore, I would like to discuss this further.

@nlohmann nlohmann added the state: please discuss please discuss the issue or vote for your favorite option label Oct 7, 2018
@nlohmann
Copy link
Owner

Anyone?

@acki-m
Copy link
Author

acki-m commented Oct 23, 2018

So no implementation?

@nlohmann
Copy link
Owner

As I described earlier, you can implement such functions with the public API. I do not think that adding theses functions to the library is a good idea as they cover a very special usecase. As there was no discussion so far, I decided to close the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state: please discuss please discuss the issue or vote for your favorite option
Projects
None yet
Development

No branches or pull requests

2 participants