Serialization + semantics of toString

[aarti_pl]

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