Creating a class instance from a string with Object.factory() method requires the name of the module:

http://www.informit.com/articles/article.aspx?p=1381876&seqNum=6

module main;
Human person = cast(Human)Object.factory("main.Human");

However, if one rename the module (let's say into "newmain"), he also has to replace all the occurences of "main.Human" into "newmain.Human" inside the same source file.

The situation is somewhat worse if the default module name is kept, that is the name of the source file. Renaming the source file will instantly break use of the .factory() method and, if the programmer is not careful to test for !is null after each .factory(), things get easily corrupted.

For these reasons, classes that belongs to the current module should (well, it's a proposal) allow a faster creation method.

Proposals:

Object.factory("Human"); // idem as Object.factory("<module name>.Human");

or

Object.factory(".Human"); // idem as Object.factory("<module name>.Human");


or

Object.factory("module.Human"); // idem as Object.factory("<module name>.Human");

The third proposal is, however, a bit cumbersome since requires the compiler to reinterpret part of a string, but it takes advantage of the fact that one canot name a module "module".

This way, one could rename source files without worrying for this issue. More, maybe it is better for the Object.factory() method to throw an exception instead of simply returning a null pointer (this will be seen even if the programmer forgot to test for null and is an alternative solution to the above proposals).

Opinions?

On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:

Alternatively, a function/variable could be provided inside the module, returning the module name as a string, so that one could write:

Object.factory(__MODULE__, ".Human");

On Fri, 26 Apr 2013 17:36:31 +0200, eles wrote:

> On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
> 
> Alternatively, a function/variable could be provided inside the module, returning the module name as a string, so that one could write:
> 
> Object.factory(__MODULE__, ".Human");

Instead of modifying the library, why not simply do this yourself?

   Object.factory(__MODULE__ ~ ".Human");

On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
> Proposals:
> Object.factory(".Human"); // idem as Object.factory("<module name>.Human");

Can't this one be done with a trivial change to the library, for strings known at compile time, by checking at compile time if the string starts with a dot? Would that be enough to alleviate the problem, or do you think more dynamic scenarios also suffer significantly from this limitation?

BTW, I was working on a Object.factory scenario right now (!) and stumbled on the limitation that the class can only have a default constructor. Couldn't you call a non-default constructor by passing var args to Object.factory()?

On Friday, 26 April 2013 at 15:36:32 UTC, eles wrote:
> On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
>
> Alternatively, a function/variable could be provided inside the module, returning the module name as a string, so that one could write:
>
> Object.factory(__MODULE__, ".Human");

I believe __MODULE__ will be available in the next release of dmd.

https://github.com/D-Programming-Language/dmd/pull/1462

--rt

On Friday, 26 April 2013 at 15:52:02 UTC, Justin Whear wrote:
> On Fri, 26 Apr 2013 17:36:31 +0200, eles wrote:
>
>> On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
>> 
>> Alternatively, a function/variable could be provided inside the module,
>> returning the module name as a string, so that one could write:
>> 
>> Object.factory(__MODULE__, ".Human");
>
> Instead of modifying the library, why not simply do this yourself?
>
>    Object.factory(__MODULE__ ~ ".Human");

Sorry, this is what I intended to write, just put a comma instead of the tilda operator.

However, I wasn't aware that the __MODULE__ symbol is predefined.

On Friday, 26 April 2013 at 16:13:44 UTC, Luís Marques wrote:
> BTW, I was working on a Object.factory scenario right now (!) and stumbled on the limitation that the class can only have a default constructor. Couldn't you call a non-default constructor by passing var args to Object.factory()?

This too, seems a good idea, but let's the more experienced to decide.

On Friday, 26 April 2013 at 16:06:14 UTC, Luís Marques wrote:
> On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
>> Proposals:
>> Object.factory(".Human"); // idem as Object.factory("<module name>.Human");
>
> Can't this one be done with a trivial change to the library, for strings known at compile time, by checking at compile time if the string starts with a dot? Would that be enough to alleviate the problem, or do you think more dynamic scenarios also suffer significantly from this limitation?

The change may be trivial (and I think it is), but a decision
must be reached first.

On Friday, 26 April 2013 at 16:13:44 UTC, Luís Marques wrote:
> BTW, I was working on a Object.factory scenario right now (!) and stumbled on the limitation that the class can only have a default constructor. Couldn't you call a non-default constructor by passing var args to Object.factory()?

Have a look at this:

https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L174

It won't call the constructor but it will create a new instance even if its construct takes arguments. You can probably call the construct using something like:

instance.__ctor(args);

--
/Jacob Carlborg