__FUNCTION__

[Edward Diener]

Andrei Alexandrescu wrote:
> Edward Diener wrote:
>> Andrei Alexandrescu wrote:
>>> Edward Diener wrote:
>>>> I argued for this in the past on this NG but still no one seems to 
>>>> have picked up the idea that a full reflection library for D, 
>>>> supported fully by the compiler, would be a great thing. It would 
>>>> also allow RAD programming with D outside of the functionality one 
>>>> could use in 3rd party tools designed around full run-time 
>>>> reflection capabilities.
>>>
>>> D2 will have reflection. (Walter doesn't know yet. He thinks D3 will 
>>> have reflection.) It will be compile-time reflection because only 
>>> run-time reflection only is missing the point.
>>
>> The whole debate about "compile-time" and "run-time" reflection  is 
>> irrelevant as long as one can invoke it without having to inject code 
>> into an already existing construct.
>>
>> It must work through run-time code which can ask such reflection 
>> questions as: enumerate for me all of the classes in a particular 
>> module etc., or enumerate for me all the functions in a class etc. . 
>> It must work by allowing code from outside of a construct to query 
>> that construct and get its accessible constructs. How that run-time 
>> code is written, whether using "compile-time" reflection using 
>> templates, or run-time classes accessible from a library whose 
>> reflection data is produced by the D compiler, is not important from 
>> the user's point of view as long as the user has the access he wants 
>> and can write relatively clean and clear code to get it.
>>
>> Of course from within any given construct one should also be able to 
>> write code in a clear manner which accesses the inner constructs.
>>
>> Access to constructs via reflection should follow the same protection 
>> features as any other code, so that public constructs are always 
>> accessible but private constructs are only accessible following their 
>> normal rules.
>>
>> So I do not know what you mean by "only run-time reflection only is 
>> missing the point" but certainly the ability to use reflection at 
>> run-time is vitally important from outside of a construct to any 3rd 
>> party tool which wants to introspect already existing constructs and 
>> create objects from those constructs based on the information run-time 
>> reflection can return.
> 
> This is a long discussion, but in brief any runtime reflection engine 
> needs some sort of compile-time metadata infrastructure. Some languages 
> don't make that accessible within the language itself. Runtime 
> reflection has been explored extensively, its possibilities and 
> limitations are pretty well understood, I hardly smothered a yawn 
> reading all you wrote. 

It was written because I have inevitably seen discussions about language 
reflection mechanisms end with talk about really neat new compile-time 
facilities which bring one no closer to real run-time reflection than 
before.

>Compile-time reflection is much less understood 
> and hides many more exciting possibilities. With the advances in 
> compiler technology implemented by Walter, we have a chance to tackle 
> reflection in a systematic manner.

Good ! I look forward to seeing it and using it in D.