Talk:Serialization

From Wikipedia, the free encyclopedia

I am having problems serializing Objects using GNU Objective-c, your example shows a serialization using a single integer. So I modified the example I created an object Fraction, instantiated a fraction object and then serialize the object, using "@" instead of "i" for the read and write methods, for the receiver portion when I print the object is 0/0 but i am able to see the address that contains the serialize values. Could anyone help me solving this I have been putting a considerable amount of time in this and I cannot get it to work.

Below I included a copy of the modified code:

______________
sender.h

  1. import <objc/Object.h>
  2. import <time.h>
  3. import "fraction.h"
//@interface Sender : Object
@interface Sender : Fraction
{
//time_t timeNow;
Fraction *timeNow;
}
- ( id ) setTime;
// replace (time_t) time
- ( int )timenum;
- ( int )timeden;
- ( id ) send;
- ( id ) read: (TypedStream *) s;
- ( id ) write: (TypedStream *) s;
- ( void ) printS;
@end
______________
sender.m

  1. import "sender.h"

@implementation Sender;
- ( id ) setTime
{
timeNow =[Fraction new];//timeNow =time(NULL);
[timeNow num:5 den:7];
return self;
}

- ( int ) timenum
{ return [self num];
}
- ( int ) timeden
{ return [self den];
}
- ( id ) write: ( TypedStream * ) stream
{
// Write the superclass to the stream.
// It is done so we have the complete object hierarchy,
// no just the object itself.

[ super write:stream ];
// Write timeNow out to the stream.
// time_t is typedef for an integer.
// The second argument , the string "i", specifies the types to write
// as per the @encode directive.
// changed "i" by "@"
objc_write_types(stream,"@",&timeNow);
return self;
}
- (id) read: (TypedStream *)stream
{
// Reverse to write - reconstruct the superclass
[super read:stream];
// Reconstruct the instance variables from the stream
// changed "i" by "@"
objc_read_types(stream,"@" ,&timeNow);
return self;
}
- ( id ) send
{ // Convenience method to do the writing. Open stdoutas our byte stream
TypedStream *s = objc_open_typed_stream(stdout, OBJC_WRITEONLY);
// Write the object to the stream.
[self write:s];

// Finish up - close the stream.
objc_close_typed_stream(s);
}

//prints a fraction
- ( void ) printS
{
[timeNow printFR];
}
______________
receiver.h

// Serialization - Sender
  1. import <objc/Object.h>
  2. import <time.h>
  3. import "fraction.h"
  4. import "sender.h"
@interface Receiver : Sender
{
//time_t t;
Sender *t;
}
- ( id ) receive;
- ( void ) printRec;
@end
__________________________
receiver.m
  1. import "receiver.h"
@implementation Receiver;
- (id) receive
{
//Open stdin as our stream for reading.
TypedStream *s = objc_open_typed_stream(stdin, OBJC_READONLY);
//Allocate memory for, and instantiate the object from reading the stream.
t=[[Sender new] read:s];
objc_close_typed_stream(s);
}
- (void) printRec
{
int num = [t timenum];
int den = [t timeden];
//prints the address the object serialized;
fprintf(stderr, "received serialized %d\n", t);
fprintf(stderr, "received serialized %d/%d\n",num, den);
}
@end




any chance some one in the know could add someting about serializable objects in .NET (direct competition of Java?).

i would be much obliged.

jaspio

What about solutions in Perl (e.g. FreezeThaw) and/or using YAML (YAML)?

isn't the term "marshaling" (with one 'l') instead of "marshalling"? the version with the double-l is only a noun, while the former has verb forms. therefore, all references to "marshall" should really be "marshal". for example, "marshaling" or "unmarshaled".

Either is acceptable. Personally I like the double-l form better.

We could add something about cloning using serialization. I wrote a Java example here : http://www.krunch.be/vrac/cours/04-05-2cinf/poo/CloneWithSerialization.java

Writing out data structures in plain text ASCII is itself a serialization and any programming language that can handle text can do this. For example Java's toString() function is often used to serialize file formats rather than using the Serializable interface. The advantage of this primitive form of serialization is that it is simple. For example in C++ serialization is also implemented using streams. However streams have a lower level of data perspective. From an data objects perspective the end of file character is no important so implementing serialization while avoiding the pitfalls of streams is dangerous. However if serialization is implemented with C++ string then the string manages the memory buffer itself and the programmer is free to focus on just writing and reading the data structure. Or when nastly low level events occure they can be managed much better. In this case the primitive technology is better.

This kind of serialization I believe is a byte stream encoding. However it uses some universal character format such as ASCII so all kinds of programms and languages can understand it. For many file formats in applications space is not the issue, for example saving a users preferences in each file is often not that costly.

Also I belief Microsofts registary is a form of serialization. Qt a Gui framework also supports the registary concept accross multiple platforms.

Could someone please consider writing this perspective in the Serialization documentation. I am not confident about how to integrate this into the existing doc. As a programmer I came to this conclusion the hard way by writing with C++ streams, and then went back to the basic text files after much grief. So I am looking to separate serialization with low level implementation and managing text files is a valid way to do it.

Contents

[edit] Serialization using Qt

Can someone please give information on serialization using Trolltech's Qt (toolkit) library? The qt designer can save/restore the GUI in xml format, is there a tutorial how it is done? Thanks!

[edit] order

I think the code examples should be ordered alphabetically by programming-language name... this way, it looks like serialization support has a higher preference in certain language environments. what do ya think? 91.34.127.3 09:36, 9 July 2007 (UTC)

[edit] Suggested change of wording

In the first paragraph it reads as follows:

...to transmit it across a network connection link, either in binary form, or in some human-readable text format such as XML.

In my opinion this should be changed as any communication using a network link is ultimately done in binary form and only after having been transmitted is, if necessary, re-converted into it's original source-format for example XML. The current wording could give the false impression that XML can be sent over a network as is; which is not possible.

[edit] Advertisement for library

Hello,

For this revision, does Wikipedia allow this type of advertisement ?

This is just a question —Preceding unsigned comment added by 213.56.245.172 (talk) 15:24, 3 October 2007 (UTC)

I'm in favor of removing it, this is not related enough to the subject and there is an open source alternative to this exact library that's not even mentioned. I will remove it, if anyone thinks this ad is justified please argue below. DanyX 17:50, 20 October 2007 (UTC)

[edit] Relationship between serializing and differential execution

I took the liberty to add a paragraph (in the Uses section) about the relationship between serialization and differential execution. I hope nobody objects too much. I think differential execution is a technique that every programmer should have in their toolkit and know when to use it. Basically, the idea is that whenever a simple, structured procedure executes, it goes through a series of decision points. If it makes a record (by serializing) of these decision points, it can later replicate the path it took (by deserializing). If it does this simultaneously with another execution, it can tell how it is differing from its prior execution. It can also serialize/deserialize arbitrary data along the way and see how that has changed. If the data being serialized/deserialized are the properties of remote objects, such as controls in a user interface, those objects can be updated incrementally. For a trivial cost in performance, the benefit is a major reduction in source code. MikeDunlavey (talk) 14:14, 26 November 2007 (UTC)