DIP 45 - approval discussion

[Dmitry Olshansky]

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