json_object_<type>_set(json_object *o,<type> value) API for value setting in json object private structure

[sdrsdr]

This will be really useful if you have a JSON representation of some internal state and when the state changes at the moment there is no way to change the JSON representation other than recreating the whole JSON tree which is suboptimal.
Implementation is quite easy if you don't switch actual object types which will be enough for may specific itch that I'm willing to scratch it is OKed by the mainteners 😄

[hawicz]

At first glance that seems reasonable, at least for primitive types. I'd say follow the the pattern json_object_set_ instead, to be consistent with existing naming.

[sdrsdr]

I've started a fork for the future merge request. The fist function is "done" with this commit ALLTERCO@fae0945
do you have any recommendations about the code style or shall I go and implement the rest with this style?

[hawicz]

json_bool should not be used as a return type to indicate success or failure. If you're going to do that, it should return an int, and use plain 1/0 constants instead of TRUE/FALSE.
However, I think it would be better to have a more "emphatic" failure by defining it to be an API usage error to call the wrong function on a particular type of object, and have the check be just an assert(jso && jso->o_type == ...) call instead.
That would then make these void functions, but it would be useful to return the original value instead. So, in the case of json_object_set_boolean(), it's return type would be json_bool like you have, but the meaning would be different.

[sdrsdr]

It is non trivial to return string value and it is memory leak prone. I prefer switching to 1 - "value" set and 0 - "error" semantic.

[hawicz]

Oh, right, handling that would mean a different approach for the string function. Ok, let's have these just return a 0/1, and if you need the previous value you can always do a ...get... call just before the ...set...