Newbie initial comments on D language - RTTI and run-time reflection

[Edward Diener]

Christopher Wright wrote:
> Jarrett Billingsley wrote:
>> "Edward Diener" <eddielee_no_spam_here at tropicsoft.com> wrote in 
>> message news:fnmaec$2j4f$1 at digitalmars.com...
>>> From the facilities mentioned at 
>>> http://digitalmars.com/d/2.0/traits.html it is hard to imagine how 
>>> one can create runtime reflection on unknown types at compile time.
>>
>> By using compile-time reflection primitives to build up metadata 
>> structures at compile time which are embedded in the app/library and 
>> which can then be used to query information about modules, the types 
>> and functions in them, etc.
> 
> The problem is locating the types that the RTTI clients might request 
> information about. I don't see a solution to this aside from requiring 
> that every RTTI-enabled type include a mixin to register itself with 
> some RTTI manager somewhere.
> 
>>> If it can indeed be done then it appears to be something that can not 
>>> be done from the outside by a 3rd party tool since that tool would 
>>> have to be able to be compiled and know about partcular types in 
>>> advance in order to gather the data it needs.
>>
>> No, it'd be done by using a tool that would parse D code into an AST, 
>> find the declarations in it, and similarly to above, generate the same 
>> kind of metadata.
> 
> Great! Now you just need the filenames that are going to be compiled 
> into the application. How do you get them?
> 
>>> I could go into the major usage of run-time reflection in modern IDE 
>>> environments but if I just say RAD programming, ala forms, 
>>> components, and design-time manipulation as in C++ Builder and later 
>>> in Visual Studio .Net, you can probably extrapolate where I am going 
>>> with it. I will just add that C++ as a a standard has been adamantly 
>>> opposed to such ideas, but from this programmer's point of view it 
>>> will be the way of programming in the future. Without real run-time 
>>> reflection RAD programming is nearly hopeless. That is the reason why 
>>> implementing it in D and working toward a RAD programming IDE using D 
>>> would be a major advantage and selling to using D over and above its 
>>> additions and possible improvements to C++ IMO. But I do realize how 
>>> difficult adding run-time reflection may be from the compiler's point 
>>> of view.
>>
>> Runtime reflection is important, yes, but for a systems programming 
>> language like D, compile-time reflection is just as important.
>>
>> FWIW The compiler already outputs some RTTI info, such as the list of 
>> modules, the classes in them, and default constructors for classes (if 
>> they exist), as well as some typeinfo representing the offsets and 
>> types of data members of aggregate types, and "Typeinfo" classes which 
>> describe the built-in and user-created/derived types.  You can see a 
>> limited form of RTTI happening in D's variadic functions -- these 
>> functions are passes an array of instances of TypeInfo classes, which 
>> correspond to the types of the arguments that were passed.
>>
> 
> That's not available until link time, though, which is too late to use 
> them in compile-time reflection.

Thanks for making the points I was initially trying to make about 
run-time reflection. A run-time reflection facility which requires some 
querying module to have pre-compiled into itself the information it 
needs to query is not a success IMO.

However I will keep my mind open about D's compile time reflection until 
I can look into it.

Is there any central documentation anywhere about D's RTTI and 
compile-time reflection mechanisms. I have been told about __traits, 
typeinfo, classinfo, RTTI, variadic functions, etc. but I really want to 
look at what D has to offer methodically and try to at least in generl 
understand it all.