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
[email protected]
http://michelf.com/
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
