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