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