Need reflection facilities

[Pragma]

Pragma wrote:
> Dave Woldrich wrote:
>> Hello all, I read on the realtime type information how-to page that 
>> there are
>> some runtime type information facilities in D.
>> (http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&id=HowTo/RealtimeTypeInformation) 
>>
>>
>> I am the author of CeeFIT (http://ceefit.woldrich.com), the C++ 
>> implementation
>> of the Framework for Integrated Test (http://fit.c2.com).  It was 
>> extremely
>> painful to implement portable reflection capabilities into C++ to 
>> mimic what
>> goes on in Java.  Basically I used every function pointer, template, 
>> macro,
>> and static linker trick I knew to pull it off (and it's still fugly.)
>>
>> If I were to implement fit for D (DeeFIT?) it would be extremely 
>> helpful to
>> have Class.forName() functionality out of the box as well as the 
>> ability to
>> get pointers-to-function and references to fields by name as well for 
>> a given
>> object.
>>
>> Would it be possible for the D compiler to generate some table of 
>> symbols or
>> synthetically generated reflection module and provide that for linkage 
>> into
>> the final binary?  Maybe the compiler could employ the same sorts 
>> template
>> specialization and static initialization techniques I used in CeeFIT to
>> generate such artifacts.  Clearly such a table could double the size 
>> of the
>> resulting .exe, but not like I care.
> 
> Howdy Dave.
> 
> To my knowledge, there are two approaches one can use to put together a 
> reflection interface on top of D, w/o hacking the compiler directly. 
> Neither is very pretty.
> 
> 1) Use the DMD front-end to compose a utility that pre-processes .d 
> files and generates the needed reflection support code.  I think there 
> are other D-ers who are doing this, but I can't recall who at the moment 
> (hasn't been much word about it lately).  I honestly don't see why this 
> can't be done today, and made to work everywhere D already does.
> 
> The facts that the front-end will furnish you with a 100% spec-compliant 
> AST, D supports the #line directive, and the spec allows for custom 
> pragma() statements, only make this approach more appealing.
> 
> 
> 2) Parse the .map file.  D's mangling specification allows for far more 
> useful information than what any C++ compiler spits out.  The result is 
> that you can extract entire call-signatures and name-spaces directly 
> from the symbol table.  I'm presently using this technique in DDL to 
> bootstrap dynamic linking with object files:
> 
> http://www.dsource.org/projects/ddl
> 
> The downside to this approach is that it leaves out just about 
> everything that can resolve to an offset or bitfield: enums, struct 
> members, class members, local vars, etc.  Otherwise, everything with a 
> vtable, call signature, typeInfo or moduleInfo is preserved and easily 
> accessed at runtime.
> 
> 
> Both approaches leave the actual reflection interface (beyond TypeInfo) 
> up for grabs.  There have been partial implementations, but nothing as 
> complete as say what .NET or Java offers.  My $0.02 on the matter is 
> that if you're first past the post on this, whatever you come up with is 
> likely to become adopted in one way or another. ;)
> 
> I hope this helps.
> 

Addendum:  Kirk is right on the money about the Don's Meta library.  You 
might be able to put something together that works via explicit 
registration of classes like so:

DeeFitRegister!(MyClass);

That said, Meta is a work of Template Ninjitsu that is hard to top. 
Tuples and the rest of D's meta programming capabilities should help you 
decompose classes and structs from there.

But if you need to answer questions like Class.nameof("Foobar"), then 
you've already out-stripped what can be done at compile-time. :)

-- 
- EricAnderton at yahoo