[phobos] Interest in having a serializer in Phobos?

[Jacob]

On 8 aug 2010, at 14:26, Michel Fortin wrote:

> Le 2010-08-08 à 1:47, Andrei Alexandrescu a écrit :
> 
>> 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);
>> 
>> and fill the object with an A. I'm pretty certain you've done that, it would be great to feature that within the tutorials and documentation. I'd also expect Variant to play a role there, e.g. you deserialize something and you get a Variant.
> 
> My own unreleased, unfinished and in-need-of-a-refactoring serialization module does that... but unfortunately dynamically recreating the right type cannot be so straightforward in the current state of runtime reflection.
> 
> This post turned out longer that I expected, please stay with me.
> 
> Runtime reflection currently gives you access *only* to the default constructor, so this is what my module do internally when unserializing a class:
> 
> 	ClassInfo c = findClass(classNameFromSerializationStream);
> 	Object o = c.create();
> 	(cast(Unserializable)o).unserialize(serialiationStream);
> 
> Since we can't access a constructor with a different signature, we can't unserialize directly from the constructor. This is rather a weak point as it forces all objects to have a default constructor. Another options is for the user to manually register his own constructor with the serialization system prior unserializing, but that's much less convenient.

Currently I don't call the constructor, just creating an instance of the class and sets its fields. I don't know how good or bad that actually is. Another option would be to use the __ctor and call one of the constructors (if it has multiple constructors) with the default values for the signature.

> The unserialize member function called above must be explicitly added by the user (either manually or with a mixin) because the fields don't reflect at runtime and the actual class is unknown at compile-time. And the class needs to conform to an interface that contains that unserialize function so we can find it at runtime.

I think that is too much extra work. One of my goals was to be able to serialize third party types.

> So before adding a serialization library, I would suggest we solve the runtime-reflection problem and find a standard way to attach various attributes to types and members. That could be done as a library, but ideally it'd have some help from the compiler which could put this stuff where it really belongs: ClassInfo. Currently, QtD has its own mixins for that, my D/Objective-C bridge has its own mixins and class registration system, my serialization module has its own, surely Orange has its own, I believe PyD has its own... this is going to be a mess pretty soon if it isn't already.
> 
> Once we have a proper standardized runtime-reflection and attribute system, then the serialization module can focus on serialization instead of implementing various hacks to add and get to the information it needs.

That is absolutely the best solution. I tried to do the best I could with the current compiler/runtime.

> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
> 
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos