Compile-time reflection

[Bruno Medeiros]

Bruno Medeiros wrote:
> 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?
> 

Ok, I don't think I made my point correctly. Yes, it's useful to 
distinguish between virtual, static and final member functions[*], but 
that's something that could be done (if not already) with 
is-expressions. What I mean is more about this:
"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."
Why would we want this change?


[*] Although, I'm not so sure about virtual vs. final distinctions.

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