I've started poking around with a reflection API for D called "dflect" and
here's what I have after a day (the zip of the files is
http://home.comcast.net/~benhinkle/dflect.zip). Comments welcome.
The basic idea is that to generate metadata about a module you run
dflect.exe (based not surprisingly on dmdfe) which takes a module foo and
generates another D source file fooinfo with auto-generated classes
describing the original module. You then compile and link in these metadata
modules into the final binary. Right now it only supports fields but I'll
start poking around with methods next. I haven't even started thinking about
templates and more complex modules. For example given the module

module test;
class Foo {
  int x;
  char[] y;
}

running dflect gives something like

// Auto-generated reflection data for module test
import dflect;
import test;
class FooInfo : MetaClass
{
    static MetaClass makeInfo(){return new FooInfo;}
    Object construct(){return new Foo;}
    this() {
      fields["x"] = new MetaField("x",typeid(int),8,4);
      fields["y"] = new MetaField("y",typeid(char[]),12,8);
    }
}
static this() {
  dflect.register("test.Foo",&FooInfo.makeInfo);
}

Here's a sample app using the resulting metadata:

import dflect;
import test;
int main() {
  MetaClass cls = getInfo("test.Foo");
  Foo u = new Foo;
  MetaField field = cls.fields["x"];
  field.set(u,100);
  field = cls.fields["y"];
  field.set(u,"hello");
  printf("setter %d %.*s\n",u.x,u.y);
  char[] res;
  field.get(u,&res);
  printf("getter %.*s\n",res);
  return 0;
}

C:\dflect\dflect>dflect test.d
C:\dflect\dflect>dmd dtest.d dflect.d testinfo.d test.d
C:\dflect\dflect>dtest
setter 100 hello
getter hello

Cool!

One question: as far as I remember order
of fields in class instances may be different from
declaration order.

How then this will reliably work for classes?:

>      fields["x"] = new MetaField("x",typeid(int),8,4);
>      fields["y"] = new MetaField("y",typeid(char[]),12,8);

I mean that dflect.exe must be always used with the
same set of command line switches as used with dmd.exe
and version of dflect.exe must be always in sync with dmd.exe.
Am I right?

BTW: does D class layout depends on command line switches?

Andrew.


"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dab8av$s2q$1@digitaldaemon.com...
> I've started poking around with a reflection API for D called "dflect" and
> here's what I have after a day (the zip of the files is
> http://home.comcast.net/~benhinkle/dflect.zip). Comments welcome.
> The basic idea is that to generate metadata about a module you run
> dflect.exe (based not surprisingly on dmdfe) which takes a module foo and
> generates another D source file fooinfo with auto-generated classes
> describing the original module. You then compile and link in these
> metadata modules into the final binary. Right now it only supports fields
> but I'll start poking around with methods next. I haven't even started
> thinking about templates and more complex modules. For example given the
> module
>
> module test;
> class Foo {
>  int x;
>  char[] y;
> }
>
> running dflect gives something like
>
> // Auto-generated reflection data for module test
> import dflect;
> import test;
> class FooInfo : MetaClass
> {
>    static MetaClass makeInfo(){return new FooInfo;}
>    Object construct(){return new Foo;}
>    this() {
>      fields["x"] = new MetaField("x",typeid(int),8,4);
>      fields["y"] = new MetaField("y",typeid(char[]),12,8);
>    }
> }
> static this() {
>  dflect.register("test.Foo",&FooInfo.makeInfo);
> }
>
> Here's a sample app using the resulting metadata:
>
> import dflect;
> import test;
> int main() {
>  MetaClass cls = getInfo("test.Foo");
>  Foo u = new Foo;
>  MetaField field = cls.fields["x"];
>  field.set(u,100);
>  field = cls.fields["y"];
>  field.set(u,"hello");
>  printf("setter %d %.*s\n",u.x,u.y);
>  char[] res;
>  field.get(u,&res);
>  printf("getter %.*s\n",res);
>  return 0;
> }
>
> C:\dflect\dflect>dflect test.d
> C:\dflect\dflect>dmd dtest.d dflect.d testinfo.d test.d
> C:\dflect\dflect>dtest
> setter 100 hello
> getter hello
> 

> How then this will reliably work for classes?:
>
>>      fields["x"] = new MetaField("x",typeid(int),8,4);
>>      fields["y"] = new MetaField("y",typeid(char[]),12,8);
>
> I mean that dflect.exe must be always used with the
> same set of command line switches as used with dmd.exe
> and version of dflect.exe must be always in sync with dmd.exe.
> Am I right?

I stumbled over that one, too. Isn't it possible to include that like this:

fields["x"] = new MetaField("x", typeid(int), Foo.x.offsetof, Foo.x.sizeof);

That should always work as expected?

Ciao
uwe

"Uwe Salomon" <post@uwesalomon.de> wrote in message news:op.stejkmuh6yjbe6@sandmann.maerchenwald.net...
>> How then this will reliably work for classes?:
>>
>>>      fields["x"] = new MetaField("x",typeid(int),8,4);
>>>      fields["y"] = new MetaField("y",typeid(char[]),12,8);
>>
>> I mean that dflect.exe must be always used with the
>> same set of command line switches as used with dmd.exe
>> and version of dflect.exe must be always in sync with dmd.exe.
>> Am I right?
>
> I stumbled over that one, too. Isn't it possible to include that like this:
>
> fields["x"] = new MetaField("x", typeid(int), Foo.x.offsetof, Foo.x.sizeof);
>
> That should always work as expected?
>
> Ciao
> uwe

You're both right. When I tried Foo.x.offsetof I got a compiler error so I
just slapped in the number. I'll post something to D.bugs so that Walter can
fix it - assuming what I saw was a bug.
I'm also thinking of not importing the original module and in that case the
fixed numbers would be the way to go.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dabv5q$1gci$1@digitaldaemon.com...
> Cool!
>
> One question: as far as I remember order
> of fields in class instances may be different from
> declaration order.
>
> How then this will reliably work for classes?:
>
>>      fields["x"] = new MetaField("x",typeid(int),8,4);
>>      fields["y"] = new MetaField("y",typeid(char[]),12,8);
>
> I mean that dflect.exe must be always used with the
> same set of command line switches as used with dmd.exe
> and version of dflect.exe must be always in sync with dmd.exe.
> Am I right?
>
> BTW: does D class layout depends on command line switches?

The only dependency I'm aware of would be version switches. Debugging and DbC switches shouldn't matter. Although to be safe I'd pass the same switches anyway.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dac14g$1ht0$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dabv5q$1gci$1@digitaldaemon.com...
>> Cool!
>>
>> One question: as far as I remember order
>> of fields in class instances may be different from
>> declaration order.
>>
>> How then this will reliably work for classes?:
>>
>>>      fields["x"] = new MetaField("x",typeid(int),8,4);
>>>      fields["y"] = new MetaField("y",typeid(char[]),12,8);
>>
>> I mean that dflect.exe must be always used with the
>> same set of command line switches as used with dmd.exe
>> and version of dflect.exe must be always in sync with dmd.exe.
>> Am I right?
>>
>> BTW: does D class layout depends on command line switches?
>
> The only dependency I'm aware of would be version switches. Debugging and DbC switches shouldn't matter. Although to be safe I'd pass the same switches anyway.

I see, thanks, Ben.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dac0na$1hg5$1@digitaldaemon.com...
>
> "Uwe Salomon" <post@uwesalomon.de> wrote in message news:op.stejkmuh6yjbe6@sandmann.maerchenwald.net...
>>> How then this will reliably work for classes?:
>>>
>>>>      fields["x"] = new MetaField("x",typeid(int),8,4);
>>>>      fields["y"] = new MetaField("y",typeid(char[]),12,8);
>>>
>>> I mean that dflect.exe must be always used with the
>>> same set of command line switches as used with dmd.exe
>>> and version of dflect.exe must be always in sync with dmd.exe.
>>> Am I right?
>>
>> I stumbled over that one, too. Isn't it possible to include that like this:
>>
>> fields["x"] = new MetaField("x", typeid(int), Foo.x.offsetof, Foo.x.sizeof);
>>
>> That should always work as expected?
>>
>> Ciao
>> uwe
>
> You're both right. When I tried Foo.x.offsetof I got a compiler error so I
> just slapped in the number. I'll post something to D.bugs so that Walter
> can fix it - assuming what I saw was a bug.
> I'm also thinking of not importing the original module and in that case
> the fixed numbers would be the way to go.

I got method dispatching working and when doing so I needed the slot number
in the vtable for each method so there are definitely going to be hard-coded
values in the metadata code. I decided to remove the import of the original
module so I'm leaving the field offset numbers. The size might get removed
and computed from the TypeInfo but for now I'll let it be.
I've also written a C header file for all this so now C/C++ code can get/set
fields and call methods on D objects using an API that roughly looks like
JNI. I'll post an update soon.

> I've also written a C header file for all this so now C/C++ code can
> get/set
> fields and call methods on D objects using an API that roughly looks like
> JNI. I'll post an update soon.

Cool. I mean extremely cool.

Probably it will be possible to make transparent interop DMDScript <-> D ...

Ben Hinkle schrieb:
> 
> C:\dflect\dflect>dflect test.d
> C:\dflect\dflect>dmd dtest.d dflect.d testinfo.d test.d
> C:\dflect\dflect>dtest
> setter 100 hello
> getter hello 
> 
> 

Sorry, i can't find dflect.d in the zip file. Where can i get it?

Markus

"Markus Dangl" <danglm@in.tum.de> wrote in message news:dakp99$273f$1@digitaldaemon.com...
> Ben Hinkle schrieb:
>>
>> C:\dflect\dflect>dflect test.d
>> C:\dflect\dflect>dmd dtest.d dflect.d testinfo.d test.d
>> C:\dflect\dflect>dtest
>> setter 100 hello
>> getter hello
>
> Sorry, i can't find dflect.d in the zip file. Where can i get it?
>
> Markus

I forgot that part. I've updated the zip file and make a page for it
http://home.comcast.net/~benhinkle/dflect/
You can call constructors and methods now. Return values are ignored
currently. Also most likely lots of little things still don't work.