[phobos] Interest in having a serializer in Phobos?
Jacob
doob at me.com
Sun Aug 8 11:39:14 PDT 2010
On 8 aug 2010, at 17:27, Andrei Alexandrescu wrote:
> On 08/08/2010 05:46 AM, Jacob wrote:
>> On 8 aug 2010, at 07:47, Andrei Alexandrescu wrote:
>>
>>> I think that would be great. Knowing nothing about Orange, I
>>> visited the website and read the feature lists and the tutorial
>>> (the reference seems to be missing for now). The latter contains:
>>>
>>> auto a2 = serializer.deserialize!(A)(data);
>>>
>>> which seems to require compile-time knowledge of the deserialized
>>> type. I'd expect the library to support something like
>>>
>>> Object a2 = serializer.deserialize!Object(data);
>>
>> This is currently not possible in the library.
>
> I see. This is probably the single most important requirement of a serialization library, by a large margin. A classic example of object orientation is the Shape hierarchy and the array of Shape objects that you draw on the screen etc. Where books are usually coy (and where classic object technology took a while to get up to snuff) is the save/restore part, e.g. once you have an array of Shapes, how do you save it to disk and how do you load it back?
>
> Saving is easy because you already know the types of objects involved so you could define a virtual function save() that is customizable per type. Loading is not that easy because you need to bootstrap object types from the input stream - and here's where the factory pattern etc. come into play.
>
> It is absolutely necessary that a serialization library makes scenarios like the above simple and fool-proof.
>
>> I'm not sure if that
>> would be possible, how would you deserialize a struct for example?
>> There is no factory function for structs like there is for classes.
>
> To deserialize a struct, I think it's reasonable to require that the receiver knows the struct statically. In the Thrift protocol things are more lax - you can e.g. write a struct Point containing two ints, and you could deserialize it as two ints. I think that's reasonable. The point is the stream contains primitive type information and class field information about all data trafficked.
>
>> Since all the static types of the objects would be Object how would I
>> set the values when deserializing?
>
> Deserialize into Object and then cast the Object to Shape.
To be able to cast it to a Shape you need to know the type at compile time when you deserialize it. Or you have to register a method that deserializes the object, which is exactly how it works now when you deserialize through a base class reference.
>> Or would Variant be useful here? I
>> have not used Variant.
>
> Probably Variant would play a role when e.g. one wants to deserialize "the next primitive type" without needing to know exactly what type that is (e.g. different integer widths).
>
>
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
I'm not sure if we understand each other correctly. If you deserialize into Object you eventually need to cast it to something more useful and then you probably could have deserialized to that type in the first place. The library can deserialize through base class references (by register a deserialize method) but you would have to start with a static type somewhere, not just Object. Do you have a simple (code) example describing what you want to do?
More information about the phobos
mailing list