Serialization

[Tim Kelliher@SimQuest]

Now that we are serializing parts of the system authors should implement
the serialization for new classes as they are created. The (temporary)
exception to this is if you are adding to a hierarchy that is not yet
serializable you can skip it. It won't be too long before everything is
done so getting used to doing it now is a good thing.

-Tim

[Harald Scheirich]

Right now we are mainly concerned with the serialization of components and their appropriate data classes, in general this will mean most of the unique public data. As all components already derive from '

Accessible', you can usually achieve serializabilty by using three steps

a) Add the SURGSIM_CLASSNAME(<fully namespaced classname>) macro to the class declaration, usually this can come right after the destructor, do not quote the classname otherwise it will become contain the " in the classname string

b) Add SURGSIM_REGISTER(SurgSim::Framework::Component,<fully namespaced classname>) to any .cpp file, in general the file that you use to implement your class. 

With these two calls in place we can create an instance of a component from its classname, the fully namespaced name is important because there are classes in differnent namespaces with the same classname, e.g. Representation 

c) For each unique public data member add a 

SURGSIM_ADD_SERIALIZABLE_PROPERTY(<classname>, <property type>, <property name>, <getter function>, <setter function>) in the constructor of the class.  

Note: Currently there is a bug that does not let you add a setter or getter for subclasses of SurgSim::Framework::Component. 

d) write a unittest that exercises  the setter and getter, test the conversion from and to a YAML node. 

This is also necessary as a lot of the infrastructure is template based, unless there is code to exercise it there might be problems that won't be discovered until the first use.

As a general rule, behaviors and components should not take other components members as parameters but those components, access to the members should be encapsulated

A remaining question is if we should unify all the interfaces on the outside to take shared pointers to Components and rather do the type conversion on the inside, or use the type neutral property access without even converting the input. There are three options 

- Only provide Exactly typed interfaces

- Only provide type neutral (std::shared_ptr<Component>) interfaces 

- provide both 

On Mon, Mar 17, 2014 at 5:07 PM, Tim Kelliher@SimQuest <tkel...@simquest.com> wrote:

Now that we are serializing parts of the system authors should implement the serialization for new classes as they are created. The (temporary) exception to this is if you are adding to a hierarchy that is not yet serializable you can skip it. It won't be too long before everything is done so getting used to doing it now is a good thing.

-Tim

--
You received this message because you are subscribed to the Google Groups "openSurgSim" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensurgsim+unsubscribe@simquest.com.
To post to this group, send email to opens...@simquest.com.
Visit this group at http://groups.google.com/a/simquest.com/group/opensurgsim/.

--

Harald Scheirich

Principal Software Engineer

Simquest Solutions Inc. 

hsche...@simquest.com