A persistent object [4,11] is one whose lifetime spans the application that created it. The state of persistent objects can be stored in files, databases or long-running processes. An object can be made persistent by simply adding a persistence meta-object to its meta-configuration.
A persistence meta-object may be implemented using two different approaches: i) it may intercept all field update operations, and update the persistent storage accordingly, possibly in background; or ii) it may update the persistent storage only when the persistent object is no longer used by the running application.
Whatever the choice, every object must be given a unique identifier, that can be used for maintaining references from one persistent object to another, as well as for reincarnating an object from persistent storage into a running application. This unique identifier might be maintained by the persistence meta-object itself, however, a unique identifier may be useful for other purposes, so we recommend the creation of a separate identification meta-object.
Whenever an object-type field of a persistent object is assigned to, the referred-to object must also be made persistent, otherwise it will not be possible to recreate the complete state of the referring object afterwards. This can be accomplished by probing the meta-configuration of this object with a broadcast message. If no persistence nor identification meta-object exists in the object's meta-configuration, the object must be reconfigured so as to become persistent, or the field assignment must be denied by throwing an exception.
In order to reincarnate a persistent object, there are two possible approaches: (i) the persistence meta-library may provide a method, that can be called from the base level, that reincarnates an object, given its unique identification; or (ii) a base-level reflective container, that represents the persistent storage, may be used to reincarnate persistent objects transparently.
An object is reincarnated by creating a pseudo-object, whose fields are filled in from the persistent storage. Reincarnation of referred objects can be done on demand, as they are accessed from the base level. Even fields might be reincarnated individually. The implementation of such meta-object would be much more complicated, but it may pay off if the object's state is large enough.