On 2013-11-13 17:29, Andrei Alexandrescu wrote:
To drive the point home: I looked once more over the code and I think
it's too complicated for what it does. It could be improved as follows.
No, I have worked on this library for several years. I don't see how it
could be less complicated for what it does. It seems you don't
understand exactly what it does.
The key to simplification is using
Object create() const;
Requires a default constructor. Not good enough.
static const(TypeInfo_Class) find(in char[] classname);
in the same type. The procedure would go as follows:
1. Retrieve the ClassInfo object for the class name.
2. Create a default-constructed object by calling create() against the
object obtained at (1).
As above, requires a default constructor. Not good enough.
3. Cast that Object down to IDeserializable, which is an interface type
that has methods such as deserialize(Archive).
* Requires a class to implement an interface. Not good enough.
* Requires the class to manually serialize itself. Not good enough.
A serialization library need to work with third party types you don't
have any control over.
4. If the cast failed, throw an exception - the object was not designed
to be deserialized.
5. Otherwise, call deserialize against that object, passing it the archive.
As above, requires the class to manually serialize itself. Not good enough.
Voila! No need for runtime registration - all user code has to do is
implement the appropriate interface.
I hope this both clarifies my point about factory being a sensible
feature, and helps you improve your library.
Unfortunately it doesn't help at all. You clearly missed a lot of
features this library has.
To be able to automatically (de)serialize an object in D you need to
know its static type. That requires registering the type. Note, this is
only needed if you're serializing through a base class reference.
You'll have to do a lot better than this to convince me.
Note also that I'm not against Object.factory/create, I'm arguing for
it. Serialization is one example of why it's needed.
The biggest reasons for why it's looking like it does are:
* Can (de)serialize arbitrary types, even third party types you don't
have any control over
* It automatically (de)serializes the objects. No need to implement a
method. You can do, if you want to customize the (de)serialization
--
/Jacob Carlborg
