From: Moritz H. <mo...@an...> - 2009-10-20 18:52:37
|
Hi, I started working on the Serializable class again. I hope to get it to improve it a lot, as it has some severe problems right now :-) The examples in the incubator will not work using the latest version, I will update that stepwise. What I want to change is that objects need to be serialized explicitly rather than just being able to serialize a single object. Thus, any class that should be serialized has to offer a readObject and writeObject method: ::CLASS "SerTest" MIXINCLASS Serializable PUBLIC ::ATTRIBUTE o ::METHOD readObject expose o use arg handler o = handler~readObject ::METHOD writeObject expose o use arg handler handler~writeObject(o) The methods can use readObject and writeObject provided by the serialization handler to save and restore the objects. This is the how serialization works in Java, for example. The new version uses 4.0 features for resolving classes. It also removes the custom handlers for rexx internal classes - in future I want all classes to serialize themselves. This is still a point where we can have a choice on how to implement it. Maybe one of you gives me a hint where to start for designing/implementing the internal class' serialization code. I also want to find out, if more methods like read/write(Logical|Number|whatever) should be added to the handler. Kind regards, Moritz |
From: Moritz H. <ant...@gm...> - 2009-10-20 18:58:00
|
[Sending mail didn't seem to work - retrying...] Hi, I started working on the Serializable class again. I hope to get it to improve it a lot, as it has some severe problems right now :-) The examples in the incubator will not work using the latest version, I will update that stepwise. What I want to change is that objects need to be serialized explicitly rather than just being able to serialize a single object. Thus, any class that should be serialized has to offer a readObject and writeObject method: ::CLASS "SerTest" MIXINCLASS Serializable PUBLIC ::ATTRIBUTE o ::METHOD readObject expose o use arg handler o = handler~readObject ::METHOD writeObject expose o use arg handler handler~writeObject(o) The methods can use readObject and writeObject provided by the serialization handler to save and restore the objects. This is the how serialization works in Java, for example. The new version uses 4.0 features for resolving classes. It also removes the custom handlers for rexx internal classes - in future I want all classes to serialize themselves. This is still a point where we can have a choice on how to implement it. Maybe one of you gives me a hint where to start for designing/implementing the internal class' serialization code. I also want to find out, if more methods like read/write(Logical|Number|whatever) should be added to the handler. Kind regards, Moritz |
From: Rick M. <obj...@gm...> - 2009-10-20 19:04:26
|
On Tue, Oct 20, 2009 at 2:57 PM, Moritz Hoffmann <ant...@gm...> wrote: > [Sending mail didn't seem to work - retrying...] I saw both versions of your mail. > > Hi, > I started working on the Serializable class again. I hope to get it to > improve it a lot, as it has some severe problems right now :-) The > examples in the incubator will not work using the latest version, I will > update that stepwise. > > What I want to change is that objects need to be serialized explicitly > rather than just being able to serialize a single object. Thus, any > class that should be serialized has to offer a readObject and > writeObject method: > > ::CLASS "SerTest" MIXINCLASS Serializable PUBLIC > ::ATTRIBUTE o > > ::METHOD readObject > expose o > use arg handler > o = handler~readObject > > ::METHOD writeObject > expose o > use arg handler > handler~writeObject(o) > > The methods can use readObject and writeObject provided by the > serialization handler to save and restore the objects. This is the how > serialization works in Java, for example. > > The new version uses 4.0 features for resolving classes. It also removes > the custom handlers for rexx internal classes - in future I want all > classes to serialize themselves. This is still a point where we can have > a choice on how to implement it. > > Maybe one of you gives me a hint where to start for > designing/implementing the internal class' serialization code. I also > want to find out, if more methods like > read/write(Logical|Number|whatever) should be added to the handler. I suspect many of the serialization methods can be more easily implemented using Rexx code rather than C++ methods. See the front of the CoreClasses.orx file for some examples of how these types of methods are added to classes that have been implemented primarily in C++ code. For example, the set-like methods that are used by the collection classes. Rick > > Kind regards, > Moritz > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Moritz H. <ant...@gm...> - 2009-10-20 19:11:32
|
Rick McGuire wrote: > On Tue, Oct 20, 2009 at 2:57 PM, Moritz Hoffmann <ant...@gm...> wrote: >> Maybe one of you gives me a hint where to start for >> designing/implementing the internal class' serialization code. I also >> want to find out, if more methods like >> read/write(Logical|Number|whatever) should be added to the handler. > > I suspect many of the serialization methods can be more easily > implemented using Rexx code rather than C++ methods. See the front of > the CoreClasses.orx file for some examples of how these types of > methods are added to classes that have been implemented primarily in > C++ code. For example, the set-like methods that are used by the > collection classes. Ok, I had a look at this class and it's good you're confirming that it is the place for adding the methods. One I have some time I plan to implement something as a proof of concept. I solved the class creation problem by passing the .context~package on deserializing the data - it will use the passed package's findClass method to locate the classes. Is this a good way of doing it or is there something better? Invoking .context~package~findClass from the serialization code does not resolve classes defined in the calling code - which is just because of a clean architecture :-) Moritz |
From: Rick M. <obj...@gm...> - 2009-10-20 19:14:21
|
On Tue, Oct 20, 2009 at 3:11 PM, Moritz Hoffmann <ant...@gm...> wrote: > Rick McGuire wrote: >> On Tue, Oct 20, 2009 at 2:57 PM, Moritz Hoffmann <ant...@gm...> wrote: >>> Maybe one of you gives me a hint where to start for >>> designing/implementing the internal class' serialization code. I also >>> want to find out, if more methods like >>> read/write(Logical|Number|whatever) should be added to the handler. >> >> I suspect many of the serialization methods can be more easily >> implemented using Rexx code rather than C++ methods. See the front of >> the CoreClasses.orx file for some examples of how these types of >> methods are added to classes that have been implemented primarily in >> C++ code. For example, the set-like methods that are used by the >> collection classes. > > Ok, I had a look at this class and it's good you're confirming that it > is the place for adding the methods. > One I have some time I plan to implement something as a proof of concept. > > I solved the class creation problem by passing the .context~package on > deserializing the data - it will use the passed package's findClass > method to locate the classes. Is this a good way of doing it or is there > something better? Invoking .context~package~findClass from the > serialization code does not resolve classes defined in the calling code > - which is just because of a clean architecture :-) I think this is an excellent way of doing this...part of the reason I added this capability :-) > > > Moritz > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |