On 11/12/13 2:36 PM, Timon Gehr wrote:
On 11/12/2013 06:46 AM, Andrei Alexandrescu wrote:
On 11/11/13 2:36 PM, Timon Gehr wrote:
On 11/11/2013 11:02 PM, deadalnix wrote:
On Sunday, 10 November 2013 at 12:39:35 UTC, Timon Gehr wrote:
What about Object.factory?
I always though of it as a misfeature.
Me too.
... well time to substantiate.
Andrei
- 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.
Correct. On the other hand, a lot of unused classes in used modules
seems to indicate a problem with the system's design.
- 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? Note that most of the time you don't "know"
the name of a class - you get it down the wire during some
deserialization. So there must be some way to build an object from a
token representation of the object.
- The functionality provided by Object.factory is trivially replaced by
a solution more specifically tailored to the problem at hand using
compile-time reflection.
It's not quite trivial - somewhere there has to be a map and
registration and lookup and whatnot. I don't see it why it's unbecoming
for such functionality to be part of the standard library. I would
agree, however, that it's a judgment call whether it should be wired in
or provided on demand.
Andrei
