Time for std.reflection

[Max Samukha]

On Saturday, 21 July 2012 at 21:44:52 UTC, Andrei Alexandrescu 
wrote:

>
> Please chime in with thoughts. Would someone want to pioneer 
> this project?
>

There are some questions.

1. static info = getModuleInfo("std.algorithm");

The language does not allow you to use CTFE parameter values as 
arguments to __traits/templates. Therefore, to be able to build 
meta-objects at compile-time, you would have to:

static info = getModuleInfo!"std.algorithm";

2. Then, what is the preferred way of referencing compiler 
objects - with strings or directly:

import std.algorithm;
static info = getModuleInfo!(std.algorithm);
?

I think using strings while we have direct access to those 
objects is not an incredibly good idea. Those strings will be 
mixed-in by getXxxInfo anyway:

ModuleInfo getModuleInfo(string name)()
{
     ...
     mixin("import " ~ name ~ ";");
     mixin("alias __traits(getMembers, " ~ name ~ ") members;");
     foreach (m; members)
     ...
}

3. auto info = getModuleInfo("std.algorithm");

There is no way to mutate global data structures at compile-time, 
therefore you would have to build, at run time, a data structure 
aggregating all meta-objects coming from various modules.

That could be achieved with static constructors:

module std.reflection;

// application-wide module info registry
private ModuleInfo[string] moduleInfos;

// run-time module info getter
string getModuleInfo(string s)
{
     return moduleInfos[s];
}

string makeModuleInfoAvailableDynamically()
{
     return q{
         shared static this() { shared static mi = 
getModuleInfo!(__traits(thisModule));
             moduleInfos[mi.name] = mi; }
     };
}

Problematic because mixing-in makeModuleInfoAvailableDynamically 
would mean that circular imports are no longer allowed for that 
module. Remember the whining babies complaining about this very 
use case a while ago?

What about changing the language so that static constructors 
marked with @system are exempted from circular dependency 
checking?

3. If you are against inheritance, why classes and not structs?

4. How the whole thing is intended to interact with dynamic link 
libraries?