function pointer bug?

[bitwise via Digitalmars-d]

> That being said, you only need to worry about any of this if 
> you want to support virtual methods and have it invoke the 
> actual overridden method, not the one you have saved through 
> reflection. (For example, if Bar : Foo overrides foo, and you 
> generated reflection info for Foo, it would call Foo.foo 
> instead of Bar.foo even if passed in an instance of Bar.)

I understand what you mean, but I don't think I need to, or 
should support that based on my current design.

Methods can be retrieved/invoked like this:

getModule("test").getClass("Bar").getMethod("foo").invoke(cast(void*)new 
Bar);

above, you would be explicitly asking for the version of 'foo' 
which is callable from an instance of 'Bar'.

i.e. Each instance of MethodDeclImpl retrieved from my reflection 
system represents exactly one method.

the type of the instance passed in will eventually be checked, 
and invoke() will throw an exception if the instance is of the 
wrong type.

In the case of a base pointer, one could use the following code:

Foo bar = new Bar;

foreach(c; getModule("test").classes)
{
     if(typeid(bar) == c.type)
         c.findMethod("foo").invoke(cast(void*)bar);
}

However, I would like to eventually have something more elegant 
than this.



> one thing to keep in mind is that something like 
> Foo!(TestClass.TestInstance) may mean multiple things, as the 
> method has overloads. At some point you may need to use 
> __traits(getOverloads) (such as in

This was next on the list =)

I just pushed support for overloaded functions, and added tests 
for virtual functions.