Compile-time reflection

[Kirk McDonald]

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

For starters, you can directly call static member functions, but not the 
others (they require an instance). The difference between virtual and 
final is more subtle, but is still worth-while to know if you start 
doing some stupid inheritance tricks.

As Jarrett points out, this information is particularly valuable when 
binding the language to another language.

>>
>> 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.
> 

This would not change that. In fact, I honestly see nothing wrong with 
that. Casting seems like simplest way of specifying the overload, 
without introducing new syntax. (Although I'm aware some folks want to 
introduce new syntax for this express purpose.)

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org