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 ?
 


D 2.0 is an experimental branch which supports compile time reflection. 
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 ?


 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.

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 ?


 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.

 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 ?


 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.

 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 

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 ?


 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.
 
 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 ?


 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.

 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 ?


 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.
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 ?


 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.
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 ?


 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
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