[phobos] Interest in having a serializer in Phobos?

[Michel Fortin]

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.

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.

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/