Edward Diener wrote:
> 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.

I agree with the importance of RTR (runtime reflection).

But as Andrei and others pointed out to me, with good compile time reflection D can achieve runtime reflection with the addition of a simple call to a library.

What this does is enable RTR on an as-needed basis, as throwing it in by default for the whole program will produce executables that are perhaps 2x the current size.

Edward Diener wrote:
> I have searched through the pdf documentation bit did not find a full
> explanation of RTTI facilities in D. The reason I ask about this is that
> it appears there is a 3rd party reflection facility but I do not see the
> documentation in D that explains if and how reflection works in D. Does
> it exist in D ? Is there documentation for it ?
> 

http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/RealtimeTypeInformation

BTW: I think that page seriously needs an update to include the new traits stuff.

-Joel

Edward Diener wrote:
> Christopher Wright wrote:
>> Edward Diener wrote:
>>> Xinok wrote:
>>>> Edward Diener wrote:
>>>>> I have searched through the pdf documentation bit did not find a full
>>>>> explanation of RTTI facilities in D. The reason I ask about this is that
>>>>> it appears there is a 3rd party reflection facility but I do not see the
>>>>> documentation in D that explains if and how reflection works in D. Does
>>>>> it exist in D ? Is there documentation for it ?
>>>>>
>>>> D 2.0 is an experimental branch which supports compile time reflection. It's documented here:
>>>> http://digitalmars.com/d/2.0/traits.html
>>>
>>> That is compile-time reflection, which is useful for creating code but not for instantiating objects at run-time and finding out about them. It is also very limiting in the form presented as one can not instantiate objects in the compile time constructs based on the information returned, but just react in a way to the information found. I am not putting down the effort as it more than duplicates and is more effective than the Boost traits library, since it is based on compiler knowledge.
>>
>> Also, you can use the classinfo for a type to create new instances of that type, provided that type has a default constructor (one that can be called with no arguments). That doesn't let you do a whole lot, I realize, but it's better than nothing.
> 
> I do not see any information in the docs about classinfo. Perhaps these things do not exist in D 1.0 and are there somewhere in D 2.0 . But without real docs for D 2.0 I will wait until there is some.


classinfo is part of the standard lib phobos and it is in 1.0:

http://www.digitalmars.com/d/2.0/phobos/object.html

Also see:

http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/RealtimeTypeInformation

-Joel

Edward Diener wrote:
>> There is flectioned (http://flectioned.kuehne.cn/), likely the library you mentioned.  The D compiler by default inserts some RTTI information, but it's not complete by any means.
> 
> Yes, that is the library but I have not looked at it yet myself. Because it mentioned reflection, I assumed that run-time reflection must be available in D in some form.

It loads an image of the executable and enumerates through the symbols that were compiled in.

Edward Diener schrieb:
> I have searched through the pdf documentation bit did not find a full
> explanation of RTTI facilities in D. The reason I ask about this is that
> it appears there is a 3rd party reflection facility but I do not see the
> documentation in D that explains if and how reflection works in D. Does
> it exist in D ? Is there documentation for it ?
> 

Here is a simple way of adding __traits based runtime reflection to D classes:

http://mainia.de/classinfoex.d
(requires DMD 2.004, by Jascha W.)

which is in fact compile-time to run-time reflection....
IMO the advantage of using this kind of runtime reflection is that you decide where runtime reflection is needed. (without producing too much bloat)
Well it requires D2 but Walter seems to be optimistic that we'll have a stable D2 at the end of the year.
Bjoern

Walter Bright Wrote:
> I agree with the importance of RTR (runtime reflection).
> 
> But as Andrei and others pointed out to me, with good compile time reflection D can achieve runtime reflection with the addition of a simple call to a library.

Just take a look at Jascha Wetzel's ClassInfoEx to see what's possible in D 2 today:

http://www.mainia.de/classinfoex.d

Adding his mixin to a class definition exposes the __traits compile time information at runtime. I expect you could also add the class name to a global registry to get at the information by name instead of classinfo.

Christian Kamm

Jarrett Billingsley wrote:
> "Edward Diener" <eddielee_no_spam_here@tropicsoft.com> wrote in message news:fnmaec$2j4f$1@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.

"Christopher Wright" <dhasenan@gmail.com> wrote in message news:fnn8o1$24d7$1@digitalmars.com...
>
> 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.

Yes, that's an issue.

> Great! Now you just need the filenames that are going to be compiled into the application. How do you get them?

Build and rebuild seem to do pretty well for themselves.

> That's not available until link time, though, which is too late to use them in compile-time reflection.

Sorry for the non sequitor in my post.  I was making two separate points with those two paragraphs, not one point leading to another.  The OP is looking for runtime reflection so I was explaining what was already available.

Robert Fraser wrote:
> Edward Diener wrote:
>>> There is flectioned (http://flectioned.kuehne.cn/), likely the library you mentioned.  The D compiler by default inserts some RTTI information, but it's not complete by any means.
>>
>> Yes, that is the library but I have not looked at it yet myself. Because it mentioned reflection, I assumed that run-time reflection must be available in D in some form.
> 
> It loads an image of the executable and enumerates through the symbols that were compiled in.

Then it has knowledge the internal structure of a module via some facility. Is this facility based on some library which gives this knowledge ? Is the internal module structure rich enough to allow all of the necessary information about types and their sub-components ?

If all this is true, then one has at least run-time reflection in the sense that information can be extracted, because the data for reflecting through the types is part of the module structure. I could care less whether the facility was based on some language internals or a library which exposed the information. I wasn't implying that the D language should have built-in facilities for run-time reflection but only that the final module should allow all of the necessary information about the types and its sub-components to be extracted. If all this is true, it is excellent news. since then the types of a module can be extracted from the module.

But that is still only half the story. Run-time reflection in a RAD environment needs the ability to be able to create an object directly from the type of that object, and the type of an object must itself be instantiable as an object. This final ability is in Java, Python, .Net, and C++ Builder/Delphi. I can only encourage D to have this ability also.

Christopher Wright wrote:
> Jarrett Billingsley wrote:
>> "Edward Diener" <eddielee_no_spam_here@tropicsoft.com> wrote in message news:fnmaec$2j4f$1@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.