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