Serialization for D. Comments, please!

[Bill Baxter]

On Tue, May 26, 2009 at 2:26 PM, Denis Koroskin <2korden at gmail.com> wrote:
> On Wed, 27 May 2009 01:23:58 +0400, Bill Baxter <wbaxter at gmail.com> wrote:
>
>> On Tue, May 26, 2009 at 12:19 PM, Denis Koroskin <2korden at gmail.com>
>> wrote:
>>>
>>> On Tue, 26 May 2009 21:44:49 +0400, Bill Baxter <wbaxter at gmail.com>
>>> wrote:
>>>
>>>> On Tue, May 26, 2009 at 2:35 AM, Denis Koroskin <2korden at gmail.com>
>>>> wrote:
>>>>>
>>>>> On Tue, 26 May 2009 13:29:39 +0400, Qian Xu
>>>>> <quian.xu at stud.tu-ilmenau.de>
>>>>> wrote:
>>>>>
>>>>>> BCS wrote:
>>>>>>
>>>>>>> I'm planning on taking a crack at a Serialization template library
>>>>>>> and
>>>>>>> I'm
>>>>>>> looking for feed back. My thinking so far is up on my blog here:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html
>>>>>>>
>>>>>>> Please comment! (here or there, doesn't matter, I think I'll see
>>>>>>> both)
>>>>>>
>>>>>> A question:
>>>>>> Should every object contain "mixin Serializable!()" in its
>>>>>> declaration?
>>>>>> It is easy to add this in own classes, but not easy to 3rd-party
>>>>>> libraries.
>>>>>> for instance: tango
>>>>>>
>>>>>>
>>>>>> --Qian
>>>>>>
>>>>>
>>>>> Good serialization library supports external serialization via template
>>>>> specialization (or similar tricks) :)
>>>>
>>>> I'll also add that you should be able to properly
>>>> serialize/deserialize a BaseClass pointer that actually points to a
>>>> DerivedClass.
>>>> This is pretty tricky to get working seamlessly when combined with the
>>>> external serialization requirement.
>>>> H3r3tic's xpose library has this working IIRC.
>>>>
>>>> --bb
>>>
>>> Sure! How about the following test:
>>>
>>> struct A
>>> {
>>>   mixin Serializable!();
>>>
>>>   B[] b;
>>> }
>>>
>>> struct B
>>> {
>>>   mixin Serializable!();
>>>
>>>   A a;
>>>   int i;
>>> }
>>>
>>> B[] b = new B[1];
>>> b[0].a.b = b;
>>> b[0].i = 42;
>>>
>>> A* a = &b[0].a;
>>>
>>> data = serialize(a); // should serialize outer struct (B), too, because
>>> it is accessible through a
>>>
>>> a = deserialize(data);
>>> assert(a.b.length == 1);
>>> assert(a.b[0].i == 42);
>>>
>>> BTW, thanks for reminding about xpose. I gotta compare it,
>>> doost.serialize and mine own one against each other in terms of efficiency
>>> and size (for binary output) someday.
>>
>> That's not quite what I meant.
>>
>> I mean this:
>>
>> /// 3RD PARTY LIB
>> class BaseClass
>> {
>>     string toString() { return "base"; }
>> }
>>
>> class DerivedClass
>> {
>>     string toString() { return "derived"; }
>> }
>>
>>
>> /// MY CODE
>>
>> [...some kind of class registration here....]
>>
>> BaseClass b = new DerivedClass;
>>
>> data = serialize(b);
>> b2 = deserialize(data);
>>
>> assert(b2.toString() == "derived");
>> ------------------
>>
>> The data stream should contain enough info about the instance to
>> reconstruct the exact derived type.
>>
>> --bb
>
> Yes, I understood and showed yet another feature which is quite hard to
> implement.

Ok.  I interpreted that as "Sure! How about the following test (of the
feature you just mentioned)".
Some segue words like "in addition" or "also" probably would have
tipped me off that you were changing the subject. :-)

--bb