www.digitalmars.com         C & C++   DMDScript  

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

reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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 ?
Jan 28 2008
next sibling parent reply Xinok <xnknet gmail.com> writes:
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 ?
 

It's documented here: http://digitalmars.com/d/2.0/traits.html
Jan 28 2008
parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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 ?

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. Is there any run-time reflection in D ? If not I would like to make a strong argument for it on this NG and then let others comment on it or at least have Walter see it. I realize implementing run-time reflection in any language is exceedingly difficult, but my argument would make a case for its importance in D if it could be done.
Jan 28 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Edward Diener" <eddielee_no_spam_here tropicsoft.com> wrote in message 
news:fnm1qm$1tiu$1 digitalmars.com...
 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 ?

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. Is there any run-time reflection in D ? If not I would like to make a strong argument for it on this NG and then let others comment on it or at least have Walter see it. I realize implementing run-time reflection in any language is exceedingly difficult, but my argument would make a case for its importance in D if it could be done.

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. The nice thing about compile-time reflection, though, is that you can use it to _create_ runtime reflection from within the language, rather than relying on a third-party tool to do so. This offers the possibility of providing runtime reflection, which is a feature not everyone needs, as part of the standard library rather than as a built-in feature of the language.
Jan 28 2008
parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Jarrett Billingsley wrote:
 "Edward Diener" <eddielee_no_spam_here tropicsoft.com> wrote in message 
 news:fnm1qm$1tiu$1 digitalmars.com...
 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 ?

It's documented here: http://digitalmars.com/d/2.0/traits.html

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. Is there any run-time reflection in D ? If not I would like to make a strong argument for it on this NG and then let others comment on it or at least have Walter see it. I realize implementing run-time reflection in any language is exceedingly difficult, but my argument would make a case for its importance in D if it could be done.

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.
 
 The nice thing about compile-time reflection, though, is that you can use it 
 to _create_ runtime reflection from within the language, rather than relying 
 on a third-party tool to do so.  This offers the possibility of providing 
 runtime reflection, which is a feature not everyone needs, as part of the 
 standard library rather than as a built-in feature of the language. 

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. 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. There is no use in the link above for using strings to pass the names of the types that one needs to reflect. So I have to believe there is more to it than the link above explains. Real run-time reflection in D would mean that: 1) One can query for the names of all types in a module given a module name. 2) One can query for all parts of a type given a type name or an object of that type. 3) One can instantiate a type given a type name and exercise that type by calling its methods, getting and setting its properties, triggering its events etc. I think you get the idea. 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.
Jan 28 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
 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.
 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.
Jan 28 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Jan 29 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Jan 29 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:
 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.

Hah. That turns it from a library into a build tool. With that, you could add reflection to assembly. With that, you get exactly one user: whoever developed it.
Jan 30 2008
prev sibling parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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.
Jan 29 2008
prev sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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.
 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.

Please, no one except a compiler itself parses source code anymore to build a reflection mechanism. If it is not in the compiler, asking a 3rd party mechanism to do it is really beyond the vast majority of programmers' ability. Sorry to be so negative but no other modern language of which I know, which has run-time reflection mechanisms, asks the programmer to go to such lengths. Look at .Net, Java, Python, Ruby, C++ Builder, or Delphi and tell me which ones ask the programmer to parse the language just to reflect on the type and their sub-components.
Jan 29 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Edward Diener" <eddielee_no_spam_here tropicsoft.com> wrote in message 
news:fnor00$ib9$1 digitalmars.com...

 Please, no one except a compiler itself parses source code anymore to 
 build a reflection mechanism. If it is not in the compiler, asking a 3rd 
 party mechanism to do it is really beyond the vast majority of 
 programmers' ability. Sorry to be so negative but no other modern language 
 of which I know, which has run-time reflection mechanisms, asks the 
 programmer to go to such lengths. Look at .Net, Java, Python, Ruby, C++ 
 Builder, or Delphi and tell me which ones ask the programmer to parse the 
 language just to reflect on the type and their sub-components.

Except that's exactly how those languages implement such things, and one of the driving goals of D is to make it easy to parse and therefore easy to write third-party tools for it. The frontend is open-source and there is in fact a project on dsource (http://www.dsource.org/projects/dmdfe) which provides the frontend in some kind of manageable form. Tools such as rebuild already use this to parse D code. Notice that .Net, Java, C++ Builder and Delphi are *aimed* at rapid app development and are all supported by major corporations, so of course those things are built in, and with Python and Ruby, such things fall out as a consequence of how they are implemented. D is a systems programming language aimed at making natively-compiled programs, so runtime reflection isn't emphasized nearly as much. Generation of runtime reflection info is not specified in the language spec, and therefore seems to me to be more of a quality-of-implementation issue than anything.
Jan 29 2008
parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Jarrett Billingsley wrote:
 "Edward Diener" <eddielee_no_spam_here tropicsoft.com> wrote in message 
 news:fnor00$ib9$1 digitalmars.com...
 
 Please, no one except a compiler itself parses source code anymore to 
 build a reflection mechanism. If it is not in the compiler, asking a 3rd 
 party mechanism to do it is really beyond the vast majority of 
 programmers' ability. Sorry to be so negative but no other modern language 
 of which I know, which has run-time reflection mechanisms, asks the 
 programmer to go to such lengths. Look at .Net, Java, Python, Ruby, C++ 
 Builder, or Delphi and tell me which ones ask the programmer to parse the 
 language just to reflect on the type and their sub-components.

Except that's exactly how those languages implement such things, and one of the driving goals of D is to make it easy to parse and therefore easy to write third-party tools for it. The frontend is open-source and there is in fact a project on dsource (http://www.dsource.org/projects/dmdfe) which provides the frontend in some kind of manageable form. Tools such as rebuild already use this to parse D code.

I repeat your first line above "Except that's exactly how those languages implement such things". Exactly ! I want the D language, or the language coupled with library(s), to handle it, not me. Since the compiler already has to parse code, what better place could their be for creating the information which could be used by a run-time reflaction mechanism. Expecting a programmer to duplicate what a compiler already does is not necessary.
 
 Notice that .Net, Java, C++ Builder and Delphi are *aimed* at rapid app 
 development and are all supported by major corporations, so of course those 
 things are built in, and with Python and Ruby, such things fall out as a 
 consequence of how they are implemented.  D is a systems programming 
 language aimed at making natively-compiled programs, so runtime reflection 
 isn't emphasized nearly as much.  Generation of runtime reflection info is 
 not specified in the language spec, and therefore seems to me to be more of 
 a quality-of-implementation issue than anything. 

The 'major corporations" argument is moot. Why is D "a systems programming language" and why is a "systems programming language" constrained against RAD development ? I do not see the connection. While Walter may decide he does not want run-time reflection because he is not interested in positioning D as a RAD development environment, or that he can add RAD development capabilities just as easily without run-time reflection ( which I admit I currently doubt, but I am open to learning about ), I would like to argue that making D capable of doing RAD development is one of the most important things which would position D as a better C++ and worthy successor. The only two other C++ development environments of which I know which offer real RAD ( design-time component development and reuse ) programming are C++ Builder and .Net C++/CLI. Both had to do it by creating their own versions of C++ with run-time reflection added. Both are utterly moribund right now, and I do not believe that either Borland or Microsoft ever seriously wanted their C++ offerings to compete with their flagship RAD products, Delphi and C#/VB respectively. Borland's support for C++ Builder has been sub-standard for years and practically worthless, and Microsoft has just publicly shown with their latest VS2008 release that C++/CLI as a RAD environment will and has been denigrated ( none of the new .Net technologies are supported in it and one of the VC++ team developers has already said quite openly that it will be treated as a second-class .Net language). D could step in where these others have failed. What an opportunity ! Finally C++ developers could have not only a more progressive language but a language which could fully support modern programming techniques and a modern IDE.
Jan 30 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jan 28 2008
next sibling parent Christian Kamm <lastname without-this-incasoftware.de> writes:
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
Jan 29 2008
prev sibling parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Walter Bright wrote:
 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).

Thanks ! Yay !
 
 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.

I sure do not care whether it is a call to a library or something built-in to the D language.
 
 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.

I sure do not mind if a compiler switch is used to add type metadata enabling run-time reflection on demand. It would be easy enough to provide two forms of a module if necessary; one slimmed down to provide only the necessary facility to run and another with all the metadata in it to allow a 3rd party mechanism to introspect through its types and sub-components for use in a possible RAD programming environment. I will look at your compile time reflecion mechanisms, if I can understand at what to look and where the documentation is. My only concern is that a run-time reflection mechanism, IMO, must not have any knowledge of types pre-compiled into it, but must be able to query type information on-the-fly at run-time. Hopefully that is the case with your facility. If it is not, no matter who Andrei is ( Aleandrescu ? ) it can not be, as far as I understand, a run-time reflection mechanism. But perhaps my understanding is limited.
Jan 29 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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.
Jan 28 2008
parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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.
Jan 29 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Edward Diener" <eddielee_no_spam_here tropicsoft.com> wrote in message 
news:fnoq19$fim$1 digitalmars.com...

 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 ?

I think it basically just uses debug symbols (on Windows anyway, on Linux I think there are more robust symbol tables), which encode the fully-qualified name of symbols to find symbols in modules. That is, it's basically just doing string processing on symbol names.
Jan 29 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Edward Diener wrote:
 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.

From http://www.digitalmars.com/d/2.0/abi.html : The class definition: class XXXX { .... }; Generates the following: * An instance of Class called ClassXXXX. [...] And from http://www.digitalmars.com/d/2.0/phobos/object.html : class ClassInfo; Runtime type information about a class. Can be retrieved for any class type or instance by using the .classinfo property. A pointer to this appears as the first entry in the class's vtbl[]. byte[] init; class static initializer (init.length gives size in bytes of class) string name; class name void*[] vtbl; virtual function pointer table Interface[] interfaces; interfaces this class implements ClassInfo base; base class static ClassInfo find(string classname); Search all modules for ClassInfo corresponding to classname. Returns: null if not found Object create(); Create instance of Object represented by 'this'. const(MemberInfo[]) getMembers(string name); Search for all members with the name 'name'. If name[] is null, return all members.
Jan 30 2008
parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Robert Fraser wrote:
 Edward Diener wrote:
 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.

From http://www.digitalmars.com/d/2.0/abi.html : The class definition: class XXXX { .... }; Generates the following: * An instance of Class called ClassXXXX. [...] And from http://www.digitalmars.com/d/2.0/phobos/object.html : class ClassInfo; Runtime type information about a class. Can be retrieved for any class type or instance by using the .classinfo property. A pointer to this appears as the first entry in the class's vtbl[]. byte[] init; class static initializer (init.length gives size in bytes of class) string name; class name void*[] vtbl; virtual function pointer table Interface[] interfaces; interfaces this class implements ClassInfo base; base class static ClassInfo find(string classname); Search all modules for ClassInfo corresponding to classname. Returns: null if not found Object create(); Create instance of Object represented by 'this'. const(MemberInfo[]) getMembers(string name); Search for all members with the name 'name'. If name[] is null, return all members.

That is start, but it looks like I will wait for 2.0 to be done before I investigate further. BTW I do realize what a major effort it is to provide metaclass information such as ClassInfo and further facilities so that full run-time reflection can be done. I would not be disappointed if D did not fully offer such facilities, but my argument here is not that I do not understand the huge effort but that once D offers that sort of facility it becomes possible do to some amazing thing with it and would be worth it.
Jan 30 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Edward Diener wrote:
 Robert Fraser wrote:
 Edward Diener wrote:
 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.

From http://www.digitalmars.com/d/2.0/abi.html : The class definition: class XXXX { .... }; Generates the following: * An instance of Class called ClassXXXX. [...] And from http://www.digitalmars.com/d/2.0/phobos/object.html : class ClassInfo; Runtime type information about a class. Can be retrieved for any class type or instance by using the .classinfo property. A pointer to this appears as the first entry in the class's vtbl[]. byte[] init; class static initializer (init.length gives size in bytes of class) string name; class name void*[] vtbl; virtual function pointer table Interface[] interfaces; interfaces this class implements ClassInfo base; base class static ClassInfo find(string classname); Search all modules for ClassInfo corresponding to classname. Returns: null if not found Object create(); Create instance of Object represented by 'this'. const(MemberInfo[]) getMembers(string name); Search for all members with the name 'name'. If name[] is null, return all members.

That is start, but it looks like I will wait for 2.0 to be done before I investigate further. BTW I do realize what a major effort it is to provide metaclass information such as ClassInfo and further facilities so that full run-time reflection can be done. I would not be disappointed if D did not fully offer such facilities, but my argument here is not that I do not understand the huge effort but that once D offers that sort of facility it becomes possible do to some amazing thing with it and would be worth it.

That's in D1, too.
Jan 30 2008
parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Robert Fraser wrote:
 Edward Diener wrote:
 Robert Fraser wrote:
 Edward Diener wrote:
 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.

From http://www.digitalmars.com/d/2.0/abi.html : The class definition: class XXXX { .... }; Generates the following: * An instance of Class called ClassXXXX. [...] And from http://www.digitalmars.com/d/2.0/phobos/object.html : class ClassInfo; Runtime type information about a class. Can be retrieved for any class type or instance by using the .classinfo property. A pointer to this appears as the first entry in the class's vtbl[]. byte[] init; class static initializer (init.length gives size in bytes of class) string name; class name void*[] vtbl; virtual function pointer table Interface[] interfaces; interfaces this class implements ClassInfo base; base class static ClassInfo find(string classname); Search all modules for ClassInfo corresponding to classname. Returns: null if not found Object create(); Create instance of Object represented by 'this'. const(MemberInfo[]) getMembers(string name); Search for all members with the name 'name'. If name[] is null, return all members.

That is start, but it looks like I will wait for 2.0 to be done before I investigate further. BTW I do realize what a major effort it is to provide metaclass information such as ClassInfo and further facilities so that full run-time reflection can be done. I would not be disappointed if D did not fully offer such facilities, but my argument here is not that I do not understand the huge effort but that once D offers that sort of facility it becomes possible do to some amazing thing with it and would be worth it.

That's in D1, too.

It may be in D1, but if it is undocumented it is doing no one any good.
Jan 30 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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 ?

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. Is there any run-time reflection in D ? If not I would like to make a strong argument for it on this NG and then let others comment on it or at least have Walter see it. I realize implementing run-time reflection in any language is exceedingly difficult, but my argument would make a case for its importance in D if it could be done.

Runtime reflection is quite weak in D. I was considering providing some facility for it for one of my projects, but that turned out not to be necessary, so I decided against it. The main problem is getting all types. You can easily register a type for RTTI with a mixin, but I'm not sure how else to do it. I thought I saw a trait to do it (__traits(derivedTypes, Object)), but I was mistaken, and such a thing would be pretty much impossible. In my situation, I didn't need nearly so much information; the trouble was passing type information to arbitrary entities. I browsed the Flectioned source once to see how it acquired runtime type information, but it scared me, and I haven't looked at it since.
Jan 28 2008
parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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 ?

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. Is there any run-time reflection in D ? If not I would like to make a strong argument for it on this NG and then let others comment on it or at least have Walter see it. I realize implementing run-time reflection in any language is exceedingly difficult, but my argument would make a case for its importance in D if it could be done.

Runtime reflection is quite weak in D. I was considering providing some facility for it for one of my projects, but that turned out not to be necessary, so I decided against it. The main problem is getting all types. You can easily register a type for RTTI with a mixin, but I'm not sure how else to do it. I thought I saw a trait to do it (__traits(derivedTypes, Object)), but I was mistaken, and such a thing would be pretty much impossible. In my situation, I didn't need nearly so much information; the trouble was passing type information to arbitrary entities. I browsed the Flectioned source once to see how it acquired runtime type information, but it scared me, and I haven't looked at it since.

I will take a look at Flectioned and perhaps the things it can do will surprise me. But I have the sneaking suspicion that I am not cognizant of all there is to know about RTTI in D as yet.
Jan 28 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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 ?

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.
Jan 28 2008
parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
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 ?

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.
Jan 28 2008
parent janderson <askme me.com> writes:
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 ?

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
Jan 28 2008
prev sibling next sibling parent janderson <askme me.com> writes:
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
Jan 28 2008
prev sibling parent Bjoern <nanali nospam-wanadoo.fr> writes:
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
Jan 29 2008