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
