Re: Serialization consternation

[Marcus G. Daniels]

>>>>> "PJ" == Paul E Johnson <address@hidden> writes:

PJ> When I try to save an agent, the serializer saves a full copy of
PJ> each agent in the listOfFriends. So when I load those objects, all
PJ> hell breaks loose.  Loading of the modelSwarm level recreates the
PJ> list of agents, and then each agent who gets "reborn" also gives
PJ> birth to a redundant set of environment objects from their
PJ> listOfFriends.

PJ> So, obviously, I have fundamentally misunderstood something about
PJ> how to design my classes and how to serialize them.

There is not a "serializer". There is a set of load and save methods
({hdf5,lisp}{In{Create},Out}), and back-end I/O primitives for
building these methods.  The serialization methods are inherited
everywhere in Swarm and the default behavior is to load and save
either flat toplevel structure or load and save recursive depth first
expansion of an object's instance variables.

The reason the case you mention doesn't work is because your model is
neither flat nor an isolated tree of objects.  It includes a list
which references other objects already saved.  Now, with Java, the way
the serialization methods work is that non-public variables are
skipped, so an easy way to get what the behavior you seek is to simply
hide all the bookkeeping variables as private.  However, with
Objective C, this metadata isn't so easily available, and so it is
necessary to solve the problem in a more general way, by writing
serialization methods that store and resuscitate objects based-on the
minimal needed information.  [Another alternative is to register your
object with an Archiver (a yellow pages for objects) and then
implement `updateArchiver', in which you save crucial pieces by name.]

One set of I/O primitives is for the Lisp or `.scm' backend and the
other set of primitives is for the HDF5 backend.  The choice of one or
the other is a tradeoff between transparency and efficency.
Serialization methods explicitly load or save each piece of data in an
object.  If you look at DefObject.m in the Swarm source distribution,
you'll see the kinds of calls that are needed, e.g. see -lispIn: or
-hdf5In:.  Discrete2d.m perhaps has a more relevant example.  The
argument to these methods is the storage object being used to load or
save.  In the case of Lisp, the storage object is a stream-like thing
(Stream, InputStream, OutputStream in collections), and in the case of
HDF5 it is a controller object (see HDF5Object.m in defobj) that
provides random-access to an HDF5 file/resource.  There are a number
of routines and methods for implementing serialization methods, but at
this point you should expect to look at the Swarm code for examples,
or at least ask directed specific questions referencing Swarm code.

Again: writing serialization methods is necessary when it is not
possible to save the state of a set of objects by recursively
expanding all the state exposed by an object's ivars or by looking at
just the toplevel structure of an object.  One way this can happen is
with opaque data (pointers) and another way this can happen is when
the structure of the set of objects has links.  Both cases require
custom programming to deal with the hidden information (known to the
class implementor) or conventions and programming to deal with pieces
of data that will be encountered cyclicly.  (This is a fact of life
when it comes to serializations schemes.)

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.