No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Re: serialize usage
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 29 Mar 2005 11:36:24 +0200
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...
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?
>
>
Date: Tue, 29 Mar 2005 11:36:24 +0200
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...
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?
>
>