www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Serialization + semantics of toString

reply aarti_pl <aarti_no_spam_ interia.pl> writes:
Jacob Carlborg Wrote:

 On 11/13/09 00:13, aarti_pl wrote:
 Andrei Alexandrescu pisze:
  > But that being said, I'd so much want to start thinking of an actual
  > text serialization infrastructure. Why develop one later with the
  > mention "well use that stuff for debugging only, this is the real
 stuff."
  >
  > Andrei

 You might want to see my serialization library for D.

 I think that it is worth noting as it manages to achieve the goal:
 same data - completely different output. Because this output might be
 defined by user in the way she wants, it seems that this can work
 exactly the way toString should work.

 It is achieved by using Archive classes which makes proper formatting,
 and which are completely independent from data being printed. Initial
 design is based on C++ Boost. I just extended concept a bit and adopted
 it to D.

 Basic interface for serialization is like this:

 auto serializer = Serializer!(TextArchive);
 //It might be also e.g.:
 //auto serializer = Serializer!(JsonArchive);
 auto input = new TransparentClass(-21, 2.11, "text1", 128, -127);
 auto output = serializer.dump(input);
 assert(serializer.load!(TransparentClass)(output) == input);

 In case of transparent classes (every field is public) you don't need
 any method inside of serialized class/struct.

 In case of opaque classes there is enough to:
 1. add mixin inside:
 mixin Serializable;
 or
 2. add template method:
 void describeUdt(T)(T arch) {
 arch.describeStaticArray(array, array.stringof);
 }

Or you could use arhc.typeof[i] to access/set the values (even private) of a struct/class.

It works exactly this way. In D1 it was not possible to access private members with tupleof[], so there was a need for describe(). But even in D2 I think that describe() should stay as it gives more flexibility for user.
Nov 13 2009
parent reply Jacob Carlborg <doob me.com> writes:
On 11/13/09 16:03, aarti_pl wrote:
 Jacob Carlborg Wrote:

 On 11/13/09 00:13, aarti_pl wrote:
 Andrei Alexandrescu pisze:
   >  But that being said, I'd so much want to start thinking of an actual
   >  text serialization infrastructure. Why develop one later with the
   >  mention "well use that stuff for debugging only, this is the real
 stuff."
   >
   >  Andrei

 You might want to see my serialization library for D.

 I think that it is worth noting as it manages to achieve the goal:
 same data - completely different output. Because this output might be
 defined by user in the way she wants, it seems that this can work
 exactly the way toString should work.

 It is achieved by using Archive classes which makes proper formatting,
 and which are completely independent from data being printed. Initial
 design is based on C++ Boost. I just extended concept a bit and adopted
 it to D.

 Basic interface for serialization is like this:

 auto serializer = Serializer!(TextArchive);
 //It might be also e.g.:
 //auto serializer = Serializer!(JsonArchive);
 auto input = new TransparentClass(-21, 2.11, "text1", 128, -127);
 auto output = serializer.dump(input);
 assert(serializer.load!(TransparentClass)(output) == input);

 In case of transparent classes (every field is public) you don't need
 any method inside of serialized class/struct.

 In case of opaque classes there is enough to:
 1. add mixin inside:
 mixin Serializable;
 or
 2. add template method:
 void describeUdt(T)(T arch) {
 arch.describeStaticArray(array, array.stringof);
 }

Or you could use arhc.typeof[i] to access/set the values (even private) of a struct/class.

It works exactly this way. In D1 it was not possible to access private members with tupleof[], so there was a need for describe(). But even in D2 I think that describe() should stay as it gives more flexibility for user.

It wasn't? When was that added? It works for me using gdc based on dmd somewhere between 1.024 and 1.030.
Nov 13 2009
parent aarti_pl <aarti interia.pl> writes:
Jacob Carlborg pisze:
 On 11/13/09 16:03, aarti_pl wrote:
 Jacob Carlborg Wrote:

 On 11/13/09 00:13, aarti_pl wrote:
 Andrei Alexandrescu pisze:
   >  But that being said, I'd so much want to start thinking of an 
 actual
   >  text serialization infrastructure. Why develop one later with the
   >  mention "well use that stuff for debugging only, this is the real
 stuff."
   >
   >  Andrei

 You might want to see my serialization library for D.

 I think that it is worth noting as it manages to achieve the goal:
 same data - completely different output. Because this output might be
 defined by user in the way she wants, it seems that this can work
 exactly the way toString should work.

 It is achieved by using Archive classes which makes proper formatting,
 and which are completely independent from data being printed. Initial
 design is based on C++ Boost. I just extended concept a bit and adopted
 it to D.

 Basic interface for serialization is like this:

 auto serializer = Serializer!(TextArchive);
 //It might be also e.g.:
 //auto serializer = Serializer!(JsonArchive);
 auto input = new TransparentClass(-21, 2.11, "text1", 128, -127);
 auto output = serializer.dump(input);
 assert(serializer.load!(TransparentClass)(output) == input);

 In case of transparent classes (every field is public) you don't need
 any method inside of serialized class/struct.

 In case of opaque classes there is enough to:
 1. add mixin inside:
 mixin Serializable;
 or
 2. add template method:
 void describeUdt(T)(T arch) {
 arch.describeStaticArray(array, array.stringof);
 }

Or you could use arhc.typeof[i] to access/set the values (even private) of a struct/class.

It works exactly this way. In D1 it was not possible to access private members with tupleof[], so there was a need for describe(). But even in D2 I think that describe() should stay as it gives more flexibility for user.

It wasn't? When was that added? It works for me using gdc based on dmd somewhere between 1.024 and 1.030.

I remember there were some problems, but it was already some time ago... Also I remember that Andrei mentioned on NG that tupleof[] should give access to all members nevertheless of their protection attributes, so I assume it was not working like this. Anyway possibility to define describe() should stay, as it gives flexibility. It is just not necessary even when members are private. BR Marcin Kuszczak
Nov 13 2009