Compile-time reflection

[Kirk McDonald]

Lutger wrote:
> Kirk McDonald wrote:
> <snip>
> 
> It would be great to have the functionality you propose in D.
> 
>>
>> 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.
>>
>> The actual syntax for this mechanism needs to be determined. D has 
>> 'static' and 'final' keywords, but no 'virtual' keyword. Additionally, 
>> the 'static' keyword has been overloaded with many meanings, and I 
>> hesitate suggesting we add another. Nonetheless, I do.
>>
>> static(A.bar == static) == false
>> static(A.bar == final) == false
>> static(A.bar == virtual) == true
> 
> 
> This looks very confusing to me, however, if you'd replace the first 
> static with 'is' it makes sense:
> 
> is(A.bar == static) == false
> is(A.bar == final) == false
> is(A.bar == virtual) == true
> 
> Is there a problem with this, grammar-wise?
> 
> Btw, if introducing 'virtual' is undesirable, it can be left out since 
> it can be inferred from being final nor static, and for this some 
> library side syntactic sugar can be made.
> 

Grammar wise, using 'virtual' would cause some problems. (What if you 
have a type called 'virtual' and want to compare some other type to it?) 
There is another, more serious, problem: is() is defined such that if 
the first thing passed to it isn't a type, it returns false. (That is, 
one of its purposes is to test if something is a valid type.) I think 
that making an exception to this rule for 'static' and 'final' could 
potentially be confusing. Therefore, some other keyword is required. I 
picked 'static' more or less arbitrarily. It also allows the use of 
'virtual' directly.

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