3 ms·

> In every application, any dependency to JSON should be minimized, contained and preferably eliminated. how do you suggest interaction with $standardised_prot

> In every application, any dependency to JSON should be minimized, contained and preferably eliminated. how do you suggest interaction with $standardised_protocol which uses JSON in that case ?

kyberias 7y ago
When implementing that protocol, dependency to JSON should be minimized, contained and preferably eliminated.
jstimpfle 7y ago
JSON is just a transport. Get the payload off from library structures to your own data structures ASAP, to remove dependencies, and to profit from your own setup. And how to make the transformation? Using your own setup. No point in expressing (duplicating!) your own data structure definitions in a random library's DDL (which, apart from the inflicted duplication, will not fit very well since it doesn't know your project).
- nepeckman 7y ago
  But this advice only really applies to projects where you create every service and layer. If you want to incorporate a 3rd party service, or want to allow your service to be used by others, you need some sort of common format. JSON isn't the most efficient, but it gets a lot of exposure from being a first class citizen of the web. Msgpack is good if you want efficiency. But you need something if you want your program to communicate with others.
- jcelerier 7y ago
  > Get the payload off from library structures to your own data structures ASAP, I don't understand, doing this step is exactly why you need to have a library such as the one which is being discussed here. There's no in-language way in C++ to go from a string that looks like `{ "foo": [1,2,3] }` to `struct { int foo[3]; }`.
  - jstimpfle 7y ago
    IMO we should not have a multi-dozens-KLOC library for something that should be almost invisible. And I don't think that being invisible is the purpose of this library. I would just specify your case as a data item: ARRAY_ITEM("foo", foo, INT, 3) And that's really all, specification-wise. Here ARRAY_ITEM is a simple macro that calculates the offset of the array within the struct (need to give the struct a name!), so that results maybe in { .srcfield="foo", .typekind=TYPE_ARRAY, .arraylength=3, .basetype=INT, offset=offsetof(MyStruct, foo) } or something like that. One can compute the length of the C array at compile time and verify that the lengths match, so there will be absolutely no danger of making a wrong data item. The corresponding code that handles the data items of kind ARRAY_ITEM would be something like this: case TYPE_ARRAY: { char *store = add_offset(&myStruct, spec->offset); int elemSize = typeKindToElementSize[spec->typekind]; JsonArray *jsonArray = get_json_array(jsonObject, spec->srcfield); for (int i = 0; i < spec->arraylength; i++) { JsonValue *jsonValue = get_json_array_element(jsonArray, i); /* This makes sure the dynamic type of jsonValue matches, then does the appropriate conversion and stores the thing. We also want to check errors, either now or at the end. */ store_json_value(jsonValue, spec->basetype, store + (i * elemSize)); } } You'll need <10, maybe 5, of these cases, and basically it's all code that you will test once and then it just works without surprises. This is less than a day of work initially, will have very low maintenance, will work exactly with the type representations you choose and be easy to change. The other aspect is you're now free from a library that you don't understand, will give you Modern C++ headaches, and will be slow to compile. I'm likely to write a new version of this for every new project, to avoid dependencies and to allow for change.
    - jcelerier 7y ago
      well, that's a possibility but only works in the simplest case of C-like structs. What if I have this API instead : struct MyWidget { void setFoos(const std::vector<int>& foos) { m_foos = foos; updateUI(); } }; or this : struct MyWidget { void addFooInstance(int); }; Also, ugh. macros. what happens if you talk to 5 different network protocols all with more-or-less-JSON-like semantics - do you now have ARRAY_ITEM_JSON, ARRAY_ITEM_BSON, ARRAY_ITEM_CBOR, ARRAY_ITEM_YAML ? What when the format changes so that `ARRAY_ITEM("foo", foo, INT, 3)` now wants floats ? woohoo, magic truncation instead of a compile error. As they say : thanks but no thanks, I'll stay with `for (auto& [key, value] : o.items())` which ensures that everyone including the fresh-out-of-school student can understand what happens without needing to read obtuse macro definitions

> In every application, any dependency to JSON should be minimized, contained and preferably eliminated. how do you suggest interaction with $standardised_protocol which uses JSON in that case ?

kyberias 7y ago

When implementing that protocol, dependency to JSON should be minimized, contained and preferably eliminated.

jstimpfle 7y ago

JSON is just a transport. Get the payload off from library structures to your own data structures ASAP, to remove dependencies, and to profit from your own setup. And how to make the transformation? Using your own setup. No point in expressing (duplicating!) your own data structure definitions in a random library's DDL (which, apart from the inflicted duplication, will not fit very well since it doesn't know your project).

nepeckman 7y ago
But this advice only really applies to projects where you create every service and layer. If you want to incorporate a 3rd party service, or want to allow your service to be used by others, you need some sort of common format. JSON isn't the most efficient, but it gets a lot of exposure from being a first class citizen of the web. Msgpack is good if you want efficiency. But you need something if you want your program to communicate with others.
jcelerier 7y ago
> Get the payload off from library structures to your own data structures ASAP, I don't understand, doing this step is exactly why you need to have a library such as the one which is being discussed here. There's no in-language way in C++ to go from a string that looks like `{ "foo": [1,2,3] }` to `struct { int foo[3]; }`.
- jstimpfle 7y ago
  IMO we should not have a multi-dozens-KLOC library for something that should be almost invisible. And I don't think that being invisible is the purpose of this library. I would just specify your case as a data item: ARRAY_ITEM("foo", foo, INT, 3) And that's really all, specification-wise. Here ARRAY_ITEM is a simple macro that calculates the offset of the array within the struct (need to give the struct a name!), so that results maybe in { .srcfield="foo", .typekind=TYPE_ARRAY, .arraylength=3, .basetype=INT, offset=offsetof(MyStruct, foo) } or something like that. One can compute the length of the C array at compile time and verify that the lengths match, so there will be absolutely no danger of making a wrong data item. The corresponding code that handles the data items of kind ARRAY_ITEM would be something like this: case TYPE_ARRAY: { char *store = add_offset(&myStruct, spec->offset); int elemSize = typeKindToElementSize[spec->typekind]; JsonArray *jsonArray = get_json_array(jsonObject, spec->srcfield); for (int i = 0; i < spec->arraylength; i++) { JsonValue *jsonValue = get_json_array_element(jsonArray, i); /* This makes sure the dynamic type of jsonValue matches, then does the appropriate conversion and stores the thing. We also want to check errors, either now or at the end. */ store_json_value(jsonValue, spec->basetype, store + (i * elemSize)); } } You'll need <10, maybe 5, of these cases, and basically it's all code that you will test once and then it just works without surprises. This is less than a day of work initially, will have very low maintenance, will work exactly with the type representations you choose and be easy to change. The other aspect is you're now free from a library that you don't understand, will give you Modern C++ headaches, and will be slow to compile. I'm likely to write a new version of this for every new project, to avoid dependencies and to allow for change.
  - jcelerier 7y ago
    well, that's a possibility but only works in the simplest case of C-like structs. What if I have this API instead : struct MyWidget { void setFoos(const std::vector<int>& foos) { m_foos = foos; updateUI(); } }; or this : struct MyWidget { void addFooInstance(int); }; Also, ugh. macros. what happens if you talk to 5 different network protocols all with more-or-less-JSON-like semantics - do you now have ARRAY_ITEM_JSON, ARRAY_ITEM_BSON, ARRAY_ITEM_CBOR, ARRAY_ITEM_YAML ? What when the format changes so that `ARRAY_ITEM("foo", foo, INT, 3)` now wants floats ? woohoo, magic truncation instead of a compile error. As they say : thanks but no thanks, I'll stay with `for (auto& [key, value] : o.items())` which ensures that everyone including the fresh-out-of-school student can understand what happens without needing to read obtuse macro definitions