No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Re: serialize usage
From: Aamer Akhter <aakhter_at_gmail.com>
Date: Mon, 4 Apr 2005 22:49:20 -0400
Gustaf,
inline
On Mar 29, 2005 5:36 AM, Gustaf Neumann <neumann_at_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?
> >
> >
>
>
Date: Mon, 4 Apr 2005 22:49:20 -0400
Gustaf,
inline
On Mar 29, 2005 5:36 AM, Gustaf Neumann <neumann_at_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?
> >
> >
>
>
-- Aamer Akhter / aakhter_at_gmail.com