Reflection Idea

Pragma ericanderton at yahoo.removeme.com
Thu Sep 28 13:04:42 PDT 2006


user at domain.invalid wrote:
>>
>> FWIW, I have the "dynamically loaded from a supplemental database 
>> file" part done.  DDL just uses the map file:
>>
>> http://www.dsource.org/projects/ddl/wiki/Tutorial/UsingDDL/Reflect
>>
>> //reflect.d
>> module reflect;
>> import ddl.DefaultRegistry;
>> import mango.io.Stdout;
>>
>> void test(){
>>     Stdout.put("Hello DDL World"c).put(CR);
>> }
>>
>> void main(){
>>     auto registry = new DefaultRegistry();
>>     auto inSitu = registry.load("reflect.map");
>>
>>     auto testFn = inSitu.getDExport!(void function(),"reflect.test")();
>>     testFn();
>> }
>>
>> It's not as pretty as Java's reflection suite, but IMO, it's only a 
>> few wrapper classes away from that level of utility.
>>
> 
> Isn't this dynamic binding rather than reflection? I think of reflection 
> as the ability to find what the fields and methods are for an object. 
> For example, with Java reflection has the following
> 
> Class c = someObject.getClass()
> c.getFields();
> c.getMethods();

Ahh, I see what you mean.  The example I cited was really more along the 
lines of binding, but it does employ a crude form of reflection to get 
to the binding step (searches through metadata for a kind of symbol).

> 
> 
> Does DDL have the ability to lookup methods and fields? 
> For example, how 
> would you determine "reflect.test" without knowing it beforehand?

Yes and no.  It does have the ability to lookup methods and fields, but 
at present, telling the difference from what you do and don't want is 
still very much DIY:

auto inSitu = registry.load("reflect.map");
foreach(module; insitu.getModules){
	foreach(symbol; module.getSymbols){
             // each symbol.name is a mangled D symbol
             // that can be inspected for it's type and namespace
             // symbol.address provides where it's actually located
	    // (ddl.Demangle.d can handle some aspects of this)
         }
}

ExporSymbols in the above cover just about everything: ModuleInfo, Class 
Definitions, ctors, dtors, functions, fields, methods and even vtables, 
initalizers, asserts and the rest of the zoo of D symbols exposed in 
.obj files.

So you can look for all the metadata you need, without having to bind to 
a given symbol.  Granted, it still feels like grocery shopping out of 
the "scratched and dented" bin.  Having a proper facade over this is a 
much needed, next step.

-- 
- EricAnderton at yahoo



More information about the Digitalmars-d mailing list