[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
saving CLOS objects
Jerry Crane writes:
>Trying to find a method to save the slot values of a series of instantiated
>CLOS objects as a cohesive block vs. recording individual values and
>re-instantiating all objects each time this program is needed. Several of
>the slots are pointers to the same or different classes of objects. Ideally,
>should be able to save to file and reload without total reprocessing.
We are writing a radiation treatment simulation system that needs to do
this also, since we create cases, run simulations and save the results.
Although there are research projects looking at the idea of "persistent
objects" and object databases, we don't see anything simple enough or
settled enough to simply use. We created a simple scheme for writing
the data from the slots of an object to a text file, and recreating the
instances from the contents of the text file. The scheme supports
having slots whose values are lists of other object instances, not
necessarily of the same class, as well as ordinary writeable and
readable lisp objects.
The functions that read and write data are implemented as ordinary
functions and are not dependent directly on the type of objects they
read and write. They achieve this by calling generic functions that
provide class-specific information, namely, (slot-type object slotname)
returns a keyword specifying whether the slot named slotname is a simple
lisp object (in which case ordinary lisp input and output will do), a
list of objects, in which case an iterative, recursive call takes care
of the list, or a large (binary) array, in which case we put the data in
a separate file. Also, since there is no way to get a list of slot
names for a class, that I know of, we provide a generic function
slots-to-save so the put-object function knows what slots to write out.
It is a few pages of code, in entirety.
The class names are written to the file as well, so the get-object
function can call make-instance as it reads the data. The format is
This scheme still incurs the overhead of make-instance, but it is hard
to see short of solving the full-blown persistent object problem how you
would avoid that.
We also support "references" to other objects, in that some slots have
the name of another object instance (of a different class) as the value.
In this case, the names persist because the objects referenced
(descriptions of radiation treatment machines) are explicitly named
externally anyway, so when they are read in, the names are always the
same (and the symbols they are bound to are the same as well).
If anyone wants a copy of this stuff, let me know and I will mail the
source files (maybe ten pages of text).
Radiation Oncology Dept.
University of Washington