DIP 45 - approval discussion

Jakob Ovrum jakobovrum at gmail.com
Tue Nov 12 16:03:47 PST 2013


On Tuesday, 12 November 2013 at 23:47:10 UTC, Andrei Alexandrescu 
wrote:
> On 11/12/13 3:05 PM, Jakob Ovrum wrote:
>> On Tuesday, 12 November 2013 at 22:36:22 UTC, Timon Gehr wrote:
>>> - Every class in any imported module will need to show up in 
>>> the
>>> generated code even if it is never used unless global static 
>>> analysis
>>> is carried out on arguments to Object.factory.
>>>
>>> - 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.
>>>
>>> - The functionality provided by Object.factory is trivially 
>>> replaced
>>> by a solution more specifically tailored to the problem at 
>>> hand using
>>> compile-time reflection.
>>
>> + 1.
>>
>> To test, I made a Factory template that works like this:
>>
>> ---
>> unittest
>> {
>>     import std.traits : fullyQualifiedName;
>>
>>     interface I {}
>>     class A : I {}
>>     class B : I {}
>>
>>     alias f = Factory!(I, A, B);
>
> Stopped reading here, and everybody should. There is a thorough 
> treatment of object factories in "Modern C++ Design" which I 
> recommend not because I wrote it, but because it's thorough. 
> Part of it is to show why the approach above is marred by 
> dependency issues and should often be avoided.

Sure, it has dependency issues, it needs to know all the types 
then and there, with is the anti-thesis of many factories. So, 
call it something else, like TypeMap, and it's still a useful 
type.

But alright, it is not a good factory.


More information about the Digitalmars-d mailing list