std.reflection prototype

[Baz via Digitalmars-d]

On Monday, 30 March 2015 at 01:11:55 UTC, bitwise wrote:
> I came across this post a while back and decided to implement 
> it:
> http://forum.dlang.org/thread/juf7sk$16rl$1@digitalmars.com
>
> My implementation:
> https://github.com/bitwise-github/D-Reflection
>
> The above conversation seemed to stop abruptly, so I went on to 
> assume that no one chose to champion the task.
>
> At the time, I looked around for other conversations or 
> attempts at runtime reflection for D, but couldn't really find 
> anything. I did find the ModuleInfo/reflection stuff in 
> object.d, but it seemed like an effort that may have been 
> abandoned. Also, the above conversation seemed to suggest it 
> should be opt-in, which also made me wonder if the stuff in 
> object.d was abandoned or for a different purpose.
>
> Looking again today, someone seems to have been working on it a 
> bit.. For example, MemberInfo_field and MemberInfo_function 
> were empty last time I checked.
>
> So what's the current state of things?
> Is anybody working on it?
>
> Although MemberInfo_field exists, it doesn't seem to be 
> available from TypeInfo_Class... Is that the eventual goal?
>
> Is there anything I can do to help get things moving?
>
>
> Any comments on my implementation would be welcome as well.
> (https://github.com/bitwise-github/D-Reflection)
>
> main.d shows some general use cases, but basically, if the 
> reflect(T) template is used on a class,
> that class, and any child types will be reflected. Recursive 
> reflection only propagates downward, or else it could leak 
> sideways and unnecessarily reflect several modules.
>
> Most of the reflection information is available at compile 
> time. For example:
>
> enum name = 
> reflectModule!(test).findClass("Test").findField("variable").name;
> pragma(msg, name); // "variable" will be outputted.
>
> To make a module available for runtime reflection, the 
> following can be used:
> mixin(runtimeReflection!test);
>
> At this point, the above example can be rewritten as:
>
> string name = 
> getModuleReflection("tests.test").findClass("Test3").findField("static_variable").name;
> writeln(name);

This is needed for sure. For example do you count how many 
subjects on .learn are about __traits(allMembers,...  or 
__traits(getMember,...

Run-time serialization is an example.

About the design i would rather see this as a user choice, eg the 
reflexion as a mixin template that you can mix in a class or a 
struct you want to be filled with info. This remark is related to 
the size problem pointed in the previous posts.