Any result

[keceli]

Status

• Ready to go

Brief Description

This PR adds serializable AnyResult class.

Detailed Description (Optional)

• Add serializable AnyResult class, addresses Require objects wrapped by AnyResult to be serializable #221.
• Use it with ModuleResult and Cache
• Add serialization to Cache class

TODOs and/or Questions

We have two classes Any and AnyResult that are identical with the only difference that the latter is serializable. We have a series of issues as discussed in #215 related to using inheritance to have a better design of these classes.

[ryanmrichard]

I didn't fully read this, but it looks like you are reverting to the copy/paste solution. What are you trying to accomplish with this PR? Are you trying to get to a point where you can work on the serialization? If so, we have other issues to address (like how are we going to dispatch between Cereal and Madness) which need tackling first. I don't want to add serialization APIs until we have a plan for what they should look like.

If I'm understanding this PR correctly it has a bunch of unmet dependencies and so it's going to need to be rewritten when the other classes exist.

[keceli]

I didn't fully read this, but it looks like you are reverting to the copy/paste solution. What are you trying to accomplish with this PR?

One of our milestones is serializing cache to disk. This PR acheives that by enabling serialization of AnyResult and Cache classes. It doesn't break downstream by using MADNESS archive type traits to check for serializability.

Are you trying to get to a point where you can work on the serialization?

Yes, it would be more efficient to enable features as long as they don't break other parts of the code. While class names, repo names are changing, hanging PRs slow down development.

If so, we have other issues to address (like how are we going to dispatch between Cereal and Madness) which need tackling first. I don't want to add serialization APIs until we have a plan for what they should look like.

I am not sure what you mean by this. We already have a Cereal wrapper in Madness archive. Serialization PR was merged before, but reverted due to #169. Now, this problem is fixed by this PR, so what is missing?

If I'm understanding this PR correctly it has a bunch of unmet dependencies and so it's going to need to be rewritten when the other classes exist.

What do you mean by unmet dependencies? This PR already works with the downstream. Edit: I guess you mean the AnyField, AnyInput classes. But, we agreed to have a working solution first and then worry about the inheritance design you suggested.

[ryanmrichard]

This is superseded by #226