Serialization + semantics of toString

Jacob Carlborg doob at me.com
Fri Nov 13 07:10:43 PST 2009


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.



More information about the Digitalmars-d mailing list