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

Edward Diener eddielee_no_spam_here at tropicsoft.com
Wed Jan 30 15:10:43 PST 2008


Jarrett Billingsley wrote:
> "Edward Diener" <eddielee_no_spam_here at tropicsoft.com> wrote in message 
> news:fnor00$ib9$1 at 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.



More information about the Digitalmars-d mailing list