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

Implement Deserialize for ContainerOptions #216

Open
zicklag opened this issue Dec 29, 2019 · 2 comments · May be fixed by #217
Open

Implement Deserialize for ContainerOptions #216

zicklag opened this issue Dec 29, 2019 · 2 comments · May be fixed by #217

Comments

@zicklag
Copy link

zicklag commented Dec 29, 2019

Is it possible to have ContainerOptions implement Deserialize? In my project I am intending to be able to serialize and deserialize a struct that contains a field of type ContainerOptions.

@zicklag
Copy link
Author

zicklag commented Dec 29, 2019

After looking into the implementation it seems like the easiest route would be to derive Serialize and Deserialize on the ContainerOptionsBuilder. Then I could store the ContainerOptionsBuilder instead of the ContainerOptions. Does that sound like a good solution to you? Would you be open to a PR?

Edit: In order to make ContainerOptionsBuilder Deserializable we have to make the param keys either owned strings or we have to make them borrowed with a lifetime. It seems like a lifetime would be annoying when trying to use the deserialized ContainerOptionsBuilder because you would have to make sure that whatever source you deserialized the value from is still in scope to use it.

How would you feel about making those keys owned strings?

@zicklag zicklag linked a pull request Dec 30, 2019 that will close this issue
@zicklag
Copy link
Author

zicklag commented Dec 30, 2019

OK, I opened a draft PR: #217. Please tell me what you think of it. 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant