Gustaf,
inline
On Mar 29, 2005 5:36 AM, Gustaf Neumann neumann@wu-wien.ac.at wrote:
Dear Aamer,
the general problem is quite tricky, when one serializes and saves some objects (e.g. containing ::xotcl::__#0), ends and restarts xotcl, creates again global objects with 'new' and restores the saved state containing the object mentioned above. 'Serialize all' does not save objects from the ::xotcl namespace, but certainly people can use -childof...
The most simple solution is to remember the highest allocated id with the saved state in serialize all, to provide a function to reset it and leave the problem to the programmer. But still, this is no good solution, if multiple save states are used and loaded in arbitary order.
A better solution is to a) check in 'new', whether an object with the generated autoname exists already, and b) provide a wrapper for loading the serialized code that extracts all patterns of autonames, and remaps some or all symbols if necessary (for handling preexisting objects with autonames). This could be done by searching for autoname patterns during serialization and using similar to the -map option of the Serializer....; but still, this only works, when the autonamed objects are serialzed; for references in variables we would need a global map table, which is still depending on the restore order of the serialized code if multiple pieces are saved.....
What are you trying? would (a) be sufficient for you? It is slightly slower than the current version, but i don't think it is worth adding another option to new for checking on demand...
hmm. for my current uses i've basically started keeping a string variable and kept on appending to it the properties i wanted in my object. at the time of creating the object, i do an md5 on the string, and get a unique key that summarizes my needed properties. I name the object the result of the md5. so across script runs the object (if it has the same properties) has the same name). for the time being this seems sufficient as i'm only serializing at specific checkpoints, and at the time of these checkpoints none of the data in the object refrences other objects.
best regards -gustaf neumann Aamer Akhter schrieb:
I just tried this with 1.3.6 and it appears to be working. Sort of related question, how do people handle the swizzling/unswizzling of autogenerated object names (eg ::xotcl__#0) when restoring an object?