Compile-time reflection

[Bruno Medeiros]

Kirk McDonald wrote:
> 
> ----
> Member functions
> ----
> 
> Here is where things get really complicated.
> 
> class A {
>     void bar() {}
>     void bar(int i) {}
>     void bar(int i, int j, int k=20) {}
> 
>     void baz(real r) {}
> 
>     static void foobar() {}
>     final void foobaz() {}
> }
> 
> class B : A {
>     void foo() {}
>     override void baz(real r) {}
> }
> 
> D does not really have pointers to member functions. It is possible to 
> fake them with some delegate trickery. In particular, there is no way to 
> directly call an alias of a member function. This is important, as I 
> will get to later.
> 
> The first mechanism needed is a way to get all of the member functions 
> of a class. I suggest the addition of a .methodsof class property, which 
> will derive a tuple of aliases of the class's member functions.
> 
> A.methodsof => Tuple!(A.bar, A.baz, A.foobar, A.foobaz)
> B.methodsof => Tuple!(A.bar, A.foobar, A.foobaz, B.foo, B.baz)
> 
> The order of the members in this tuple is not important. Inherited 
> member functions are included, as well. Note that these are tuples of 
> symbol aliases! Since these are function symbols, all of the mechanisms 
> suggested earlier for regular function symbols should still work!
> 
> tupleof(A.bar) => Tuple!(void function(), void function(int), void 
> function(int, int, int))
> 
> And so forth.
> 
> There are three kinds of member functions: virtual, static, and final. 
> The next important mechanism that is needed is a way to distinguish 
> these from each other. An important rule of function overloading works 
> in our favor, here: A given function symbol can only refer to functions 
> which are all virtual, all static, or all final. Therefore, this should 
> be considered a property of the symbol, as opposed to one of the 
> function itself.
> 

Why would we need to distinguish between virtual, static and final 
member functions?

> 
> Given these mechanisms, combined with the existing mechanisms to derive 
> the return type and parameter type tuple from a function type, D's 
> compile-time reflection capabilities would be vastly more powerful.
> 

I'm not sure about some of the detail, but in a general wey, yes it 
would be welcome to have such changes that would allows us to better 
work with functions. Some of the issues here are not just about compile 
time reflection, for instance, that you have to create a temporary type, 
or do a cast, to get a function pointer of a particular overload, seems 
quite hackish to me.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D