DIP 45 - approval discussion

[Andrei Alexandrescu]

On 11/12/13 7:05 PM, Timon Gehr wrote:
> On 11/13/2013 03:48 AM, Andrei Alexandrescu wrote:
>> On 11/12/13 6:26 PM, Timon Gehr wrote:
>>> On 11/13/2013 03:15 AM, Andrei Alexandrescu wrote:
>>>> ...
>>>>>>> - If I know the fully qualified name of a class, there are better
>>>>>>> ways
>>>>>>> to instantiate this class than passing a string containing that
>>>>>>> name to
>>>>>>> Object.factory in order to call the default constructor.
>>>>>>
>>>>>> What are the better ways?
>>>>>
>>>>> Call the default constructor. Call a delegate/virtual function that
>>>>> calls the default constructor.
>>>>
>>>> Wait, doesn't Object.factory call the default constructor of the
>>>> created
>>>> object?
>>>> ...
>>>
>>> Yes, I was listing some ways to do this that I think are better than
>>> calling Object.factory.
>>
>> OK I think I figure you are confused.
>
> I'm not.

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.

>> You can't call the default
>> constructor of an object you don't know the type of.
>>
>> Andrei
>>
>
> Indeed. There was a premise stating that I do. :o)

So you say Object.factory is a misfeature based on a use case that 
solves a very different problem?

> In any case, the only use for string -> new object is when there is some
> kind of parsing going on (and then you should make sure in some way that
> only objects of types in some well-defined subset can be constructed),
> otherwise you can always pass around richer data structures, such as an
> actual factory object.

No parsing needs to be involved, as in e.g. binary formats. And I'm 
talking data not code, which excludes passing around a factory object.


Andrei