Catacomb can save its models in two formats - a vaguely c-like structure assignments compatible with Yorick and as the same text but embedded in a static method in a Java class file. The latter must be compiled with the Java compiler before it can be reread: its main advantage is that the resulting class files can be packaged with Catacomb in a single jar archive.
An example if a portion of a saved file shown below.
//YS;
ob0 = catacomb.ksCell (
name = "anon",
color = 933875,
daughterDisplay = 1,
instanceInfo = "",
fieldvis = &[8, 8, 8, 8, 8, 0, 0, 0, 0, 0, 0, 0, 0],
isDefault = 0,
ions = monovec (
name = "ksIon",
className = "ksIon",
daughterDisplay = 1,
popa = &[&catacomb.ksIon (
name = "sodium",
color = 13088725,
daughterDisplay = 1,
instanceInfo = "",
fieldvis = &[8, 8, 8, 8, 8, 0, 0],
isDefault = 1,
Catacomb objects are saved as structure declarations containing name=value pairs to set their fields. In Yorick, an ampersand returns an reference to its argument, and square brackets define arrays. Array fields of Yorick objects can have arbitrary dimensions, whereas array fields of c structures must have their size specified in the structure declaration. Therefore, arrays are stored as references to arrays, (which in fact they are in Java objects). Hence, for example, the & in setting the fieldvis array.
Arrays may contain elementary data types or pointers, but not Yorick objects, so when a list of objects is saved it is written as though it was a pointer to an array of pointers to the objects. Since Java does not have explicit pointers, there is no ambiguity in parsing such constructs within Catacomb.
One difficulty of saving interconnected objects is in storing their cross references. In Catacomb the problem is not very severe because it uses such a restricted data structure. Only two Catacomb classes are allowed to make variable references to other objects, of which only one is common. List selectors (CcmbSelections in the code) select some or all of the elements of a list of objects defined elsewhere. When saved, they just save the name and class of the target list, and on restoration, Catacomb fishes out all the defined lists and lets the list selectors pick out the ones they want. This covers most possible applications, and for the rest, Catacomb objects contain a privateInit method which is run after an object is restored which should set up any state information which is not saved.
The other cross object reference is the CcmbReference which can point to almost anything - an object, a wrapped field or an array. This is saved just by the target name, and looked up dynamically in the current model when required.