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);
static assert(is(f.Product == I));
I a = f.create(fullyQualifiedName!A);
assert(cast(A)a);
I b = f.create(fullyQualifiedName!B);
assert(cast(B)b);
}
---
Some notes:
* The first parameter, the Product parameter, which can be any
class or interface, is required because CommonType is always
Object when given a heterogeneous list of classes. I assume this
is because of the difficulty of choosing a common interface when
multiple interfaces are present.
* All subsequent parameters, the factory provider classes, are
of course checked that they actually implement the Product,
whether as a base class or an interface. Is a bit of a gotcha
because AliasThis has to be "worked around" in the checking code.
* Implementation uses a sorted array instead of an AA because
AAs can't be transferred from CT to RT yet.
* The array is immutable, so the same list is used for the same
Factory across threads (but I suppose that has no real
significance, just an observation).
* If the Product member is deemed unnecessary, it could just be
a function template instead of a template with two members
(Product and create).
Advantages over Object.factory:
* The opCall returns Product, not Object, so client code doesn't
need to cast in most circumstances.
* `fullyQualifiedName` is used in the example because it
internally uses `TypeInfo_Class.create`, which requires the full,
internal names of the A and B types, which of course, are nested
in a unittest. However, since the range of implementations are
known, it could be amended to statically figure out a less strict
naming scheme. In this case, just "A" and "B" could be made valid
without ambiguity. Object.factory cannot practically do this.
* Interestingly, since it knows all the constructors, it could
present an overload set of the constructors that all implementors
support, with some implementation effort!
* Lookup has the opportunity to be a lot faster than
Object.factory due to the smaller set of providers.
* The runtime list of providers does not contain types that
aren't part of the set (duh), hence no bloat.
The disadvantage is that all implementing types must be passed at
compile-time. That is the only advantage of Object.factory,
AFAICS. As it seems like a very niche need that everyone has to
pay for, I don't think Object.factory carries its weight.
