• aarti_pl <aarti_no_spam_ interia.pl> Nov 13 2009
• Jacob Carlborg <doob me.com> Nov 13 2009
• aarti_pl <aarti interia.pl> Nov 13 2009

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.

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.

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