This follows a comment I made in #241 which was out of scope for the that pull request. This issue is also touched on in #34.
The current proposition is:
Define a "JsonableInterface" that supports something like to_json() and from_json() (static?) methods (the latter of which is a factory method). The idea then is that then users can:
foo_object = Foo(...) # regular way
# or
foo_object2 = Foo.from_json(valid_foo_object.to_json()) # maybe **valid_foo_object.to_json()
In simple cases, we can just set from_json = __init__.
Any object that should be json-able should implement these two functions.
Superclasses can implement baseline methods and subclasses can extend the resulting dicts and/or access extra json members in construction.
Longer term, it'd be nice to accomplish the general goal of #34 which is to hook our colander schema deserialize/serialize functions up to the MOE classes directly. That is, we override colander's serialize/deserialize methods to call the to/from_json() methods of the object that the schema represents.
This may also let us push validation into objects (instead of having objects and schemas validate separately right now).
This follows a comment I made in #241 which was out of scope for the that pull request. This issue is also touched on in #34.
The current proposition is:
Define a "JsonableInterface" that supports something like
to_json()andfrom_json()(static?) methods (the latter of which is a factory method). The idea then is that then users can:In simple cases, we can just set
from_json = __init__.Any object that should be json-able should implement these two functions.
Superclasses can implement baseline methods and subclasses can extend the resulting dicts and/or access extra json members in construction.
Longer term, it'd be nice to accomplish the general goal of #34 which is to hook our colander schema deserialize/serialize functions up to the MOE classes directly. That is, we override colander's serialize/deserialize methods to call the
to/from_json()methods of the object that the schema represents.This may also let us push validation into objects (instead of having objects and schemas validate separately right now).