On 30/03/2015 2:11 p.m., bitwise wrote:
I came across this post a while back and decided to implement it:
http://forum.dlang.org/thread/[email protected]

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);

I love the idea of it.
But first we need to finish off what support we damn well have in druntime.

m_offTi for TypeInfo_Class currently is not being generated.

We also need some form of RTInfo for modules. Not just for symbols. This alone will open up quite a few doors!

Reply via email to