13-Nov-2013 22:46, Andrei Alexandrescu пишет:
On 11/13/13 10:41 AM, Dmitry Olshansky wrote:
13-Nov-2013 13:27, Andrei Alexandrescu пишет:
On 11/13/13 12:55 AM, Jacob Carlborg wrote:
On 2013-11-13 05:07, Andrei Alexandrescu wrote:
Then how do you figure doing this:
class Streamable { ... }
class Foo : Streamable { ... }
class Bar : Streamable { ... }
string className = stream.readln();
Streamable obj = ...;
How do you create obj from className, when className could be either
"Foo" or "Bar"? In the general case there could be any number of
classes, in different modules.
This requires Object.factory (or equivalent) and that all subclasses
have been registered as well.
With Object.factory that's taken care of already.
I have to chime in.
Serialization != calling default constructor by name.
Of course not. It does give you access to an object with the correct
dynamic type, and interfaces and virtual calls take care of the rest.
Allow me to retort, see below.
BTW the keywords here were:
_default_ and _by name_
Simply on the ground of "solves problem in too narrow scope for a hefty
coast to the user" I'd drop it.
It's good. Let's keep it.
Oh, my... We've lost him :o)
Okay. Let me iterate on some facts:
1. Serialization may or may not be intrusive. There are many cases out
there to externalize serialization (see e.g. boost serialization).
2. Want speed - avoid virtuals. Requiring that serialization be always
done via specific virtual call harms performance.
3. Something you seem to dodge - AA lookup by fully qualified name is
not fast nor convenient for many serialization backends.
4. Not everything needs to be serialized yet it's registered (and slows
down lookups).
5. Forcing a pattern - every class object must be default constructible.
Btw what factory does with these not defining this() ? Sadly the reality
is the other way around - many interesting objects don't have valid
default states.
Another point that is not a fact but rather a speculation.
I _think_ that the idea of having user pay beforehand for something
simply because it may one day need it is going against D ethos. Unlike
Java or .NET we have definite trend of catering for specific needs and
extreme flexibility at no extra cost.
--
Dmitry Olshansky
