On Mon, 24 Dec 2001, Gunther Birznieks wrote: > >---------- Forwarded message ---------- > >Date: Sun, 23 Dec 2001 11:51:00 -0000 > >From: Jean-Michel Hiver <[EMAIL PROTECTED]> > >To: brian moseley <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > > Gunther Birznieks <[EMAIL PROTECTED]> > >Subject: Re: transient object data > > >With this interface it would be possible to subclass Serializable with > >Serializable::FreezeThaw, Serializable::DataDenter or > >Serializable::XMLDumper for instance (just override the _freeze and thaw > >methods). The objects can also redefine the clone() method if they need to. > > > >Now there's only one drawback that I can see - It needs to be written :-)
well i'm a victim of jet lag tonight, so here's a proposal :) find it at http://www.maz.org/perl/Serializer-0.01.tar.gz. i took a combination of your and gunther's suggestions and mixed in a few of my own ideas. the result: o Serializer: abstract class that defines a generic serialization api - freeze() and thaw(). implementations provide _freeze() and _thaw(). o Serializer::DataDumper - Data::Dumper implementation o Serializer::DataDenter - Data::Denter implementation o Serializable: abstract base class for serializable objects. implementations provide clone() and make use of mark_transient(). the Serializer calls remove_transients() from within freeze() and add_transients() from within thaw(). the neatest thing is that the existing serializers don't have to be modified to look for transient data. the Serializer wrapper removes and restores transient data itself. mark_transient() allows the Serializable to optionally specify class names for each transient variable such that a new instance of each transient can be created when the object is thawed. issues: - there should probably be a Serializer factory method that looks at an environment variable or something to determine which implementation to use. anybody have any preferences? - when specifying class names for transient variables to be reconstructed at thaw time, should we also be able to specify parameters for the constructor? ex: "FileHandle open r" instead of "FileHandle" if you think these objects should behave like java beans, then the answer is no. - what would a default implementation of Serializable::clone() look like? - what exactly should be the definition of clone anyway? a few weeks ago i doodled around implementing interesting bits of java.lang.Object in perl. for clone, i decided that ref($x->clone()) eq ref($x) and that the operation performs a shallow copy. thoughts? - have i missed anything? this is simply a stab at defining a direction, let me know what holes i've stumbled past in the dark. thanks!
