Is there a nice way to associate external values with json elements?

[timprepscius]

I am contemplating caching deserializations of json subtrees within the json tree.
Is there a clean way of doing this without modifying your code?

json j = { ... };
auto myPrivateDeserialization = makeMyPrivateDeserialization(j["bigtreeofdata"]);
j["bigtreeofdata"].privateDeserialization = myPrivateDeserialization;

[timprepscius]

Well, no response, so I would like to modify my question to be:

What is the best way to modify your library to allow for custom values bound to elements.
I'm thinking to modify your class basic_json class to derive from a custom class. I would like that to be a template parameter, but it seems like this might be difficult to do, because there are so many template parameters already.

using caching_json = ...::basic_json<caching_class>;

I think I would also need to change swap, to call a base class swap if there is one, I guess.

Would this be the best way to go about it? Can you think of a better way?

[nlohmann]

I am currently not aware of a nice means to extend the class. Any help appreciated.

[nlohmann]

Maybe related: #1201.

[timprepscius]

We can't extend it via deriving from basic_json and then declaring the manipulating the template parameter of the allocator, because the object_t map is a map of basic_json and not a map of basic_json*.

I think the above statement is true. I could be wrong.

This means that in order to associate external values we must either 1. have another template parameter, "customization field", 2. or change basic_json's derivation.

I think the above statement is true. I could be wrong. There are other options of using the deserialization listener of the json to create a parallel structure, but I am trying to avoid that, at least in theory.

1. Template parameter. I don't see why there could not be a template parameter of "external_value" and have it default to an empty struct typedef.

On the copy, swap methods of the json, you would need to copy and swap the external values as well. This would be trivial, and incorporating different structures, one would merely need to specialize whatever template method is used to do this copy/move/etc.

For an empty structure external value, I would assume the compiler would optimize these extra instructions out, and indeed, I would guess that the memory size of the json class would not change.

I'm guessing it would be maybe 10-20 extra lines of code.

2. Deriving from a template parameter base type. For my special case, I can only personally see draw backs for this. While it will allow for a more interesting json specializations, it will cause the hassle of worrying about if that move/copy/etc needs be virtual or not, when to call what methods.

Those are my thoughts at the moment.

[nlohmann]

So idea 1 would just mean that you add an arbitrarily-typed (public?) member variable to the basic_json class?

[timprepscius]

Yep. Seems dirty. Lol. But if it were an empty struct by default... I would guess it would be optimized out.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.