-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Port has_shape from dropbox/json11 #528
Comments
Usage: auto check = shape_t {
{"name", json::value_t::string},
{"ttl", json::value_t::number_unsigned}
};
if (has_shape(js, check, err)) {
cout << "Conforming object" << endl;
} else {
cout << "Non-conforming object: " << err << endl;
} |
|
I'm not sure whether such a function needs to be added. This sort of validation goes into the direction of JSON Schema or so, and is rather specific. Before we discuss specifics of a PR, let's talk about why this exact function is useful in which scenarios. |
Well, it's a very convenient check that the object you received conforms to several assumptions at once. Instead of checking field-by-field in a very clumsy manner if (json.find(FIELD) != json.end and json.find(FIELD).type() == json::string) {
json.find(FIELD).get<string>() do something with it
}
if (json.find(ANOTHER) != json.end and json.find(ANOTHER).type() == json::number_unsigned) {
json.find(ANOTHER).get<int>() do something with it
}
if (json.find(THIRD) != json.end and json.find(THIRD).type() == json::number_unsigned) {
json.find(THIRD).get<int>() do something with it
}
if (json.find(FOURTH) != json.end and json.find(FOURTH).type() == json::number_unsigned) {
json.find(FOURTH).get<int>() do something with it
}
// it can be more than four fields here, e.g. a typical github api response would contain more than 10 you just specify expectation of what the object should look like and check in one go if (!json.has_shape({
{FIRST, string},
{SECOND, number_unsigned},
{THIRD, string}
{FOURTH, array}
{FIFTH, object}
}))
throw runtime_error("eh, not what i expected");
json[FIRST].get<string>() etc you can use further without any checks - it's there I find this pattern repeatedly convenient when using json, even if I don't require full-fledged schema validation. It's just less to type and less syntax errors to make. ( |
Any thoughts on this? |
I think that the proposal is great but probably is better if we can see in "embedded" style:
I use an approach similar to that on a simple messaging system based Actor Model (powered by ZMQ & nlohmann::json). I think that this could transform a lot of code if few lines. |
It seems this check can be realized entirely with public methods, right? |
I don't see this as an extension to the library that is useful for many. It is a very special use case, makes only sense for JSON objects, and after all, it can be realized entirely with public methods. Therefore, I tend to close this issue unless I missed something. |
It has a very nice utility function, which I ported to nlohmann/json for myself, but would be nice to have it as part of the class:
The text was updated successfully, but these errors were encountered: