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

Make optional user-data available in from_json #864

Closed
chadlayton opened this issue Dec 8, 2017 · 8 comments
Closed

Make optional user-data available in from_json #864

chadlayton opened this issue Dec 8, 2017 · 8 comments
Labels
solution: proposed fix a fix for the issue has been proposed and waits for confirmation solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)

Comments

@chadlayton
Copy link

chadlayton commented Dec 8, 2017

I'd like to be able to supply optional user-data to json::parse which would then be retrievable in from_json. A naive implementation might look like this:

void from_json(const json& j, image& img, void* user_data)
{
	const char* root_directory = reinterpret_cast<const char*>(user_data);
	std::string filename = j["filename"];

	img.data = load_external_dependency(std::string(root_directory) + "//" + filename);
}

// ...

json j = json::parse(json_string, "C:\\images\\");

Or maybe this is already possible? Right now the only way I can see to do it requires global state or caching the data on the object and fixing it up after parsing.

@theodelrieu
Copy link
Contributor

I have thought about it, but I fail to see how the library could call from_json with the extra argument.

I would say that such logic should be avoided in from_json, you can always embed that in your type.

Could you precise your use case?

@chadlayton
Copy link
Author

My exact use case is very much like the one I shared except the root directory isn't hard-coded. In practice it will be relative to wherever the json was loaded from. For example:

C:/models/
  badguy/
     badguy.json
       { "filename" : "images/badguy.png" }
     images/
       badguy.png

I'd prefer to not save the filename at all since only the data is important. And I don't want to use global state since there could be multiple threads doing jobs that require different root directories. Another option for the user data would be caching it on the json object itself somehow?

@jaredgrubb
Copy link
Contributor

I would like to see a visitor-based parse API, which would be perfect for things like this. (Would also make it possible to implement a "does it parse" API as well as many other variants). Something like:

MyVisitorWithExtraStuff visitor{helpfulThing1, helpfulThing2};
auto parsedThing = json::parse(visitor, source);

@gregmarr
Copy link
Contributor

gregmarr commented Dec 9, 2017

@jaredgrubb Like this?

https://github.com/nlohmann/json/blob/develop/src/json.hpp#L12914-L12916

static basic_json parse(detail::input_adapter i,
                        const parser_callback_t cb = nullptr,
                        const bool allow_exceptions = true)

@jaredgrubb
Copy link
Contributor

Hm... I didn't know that was there! I'll have to see if that will do what I was hoping.

@nlohmann nlohmann added the solution: proposed fix a fix for the issue has been proposed and waits for confirmation label Dec 12, 2017
@nlohmann
Copy link
Owner

Can I close this issue?

@chadlayton
Copy link
Author

I think @jaredgrubb found a solution to his problem but mine is still the same as presented originally - wanting to pass some kind of user-data / context through to the from_json methods. It's a just a feature request though so of course you're free to close the issue if you like :)

@nlohmann
Copy link
Owner

I think we are not able to make this extension. The whole from_json stuff is pretty advanced, and if @theodelrieu has no idea, then we are out of luck.

@nlohmann nlohmann added the solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope) label Dec 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
solution: proposed fix a fix for the issue has been proposed and waits for confirmation solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)
Projects
None yet
Development

No branches or pull requests

5 participants