Need reflection facilities

[Dave Woldrich]

== Quote from Georg Wrede (georg at nospam.org)'s article
> Dave Woldrich wrote:
> > If I had reflection in a systems-programming language like D, the tools that could
> > be written to work with D would be incredible.
> You might want to elaborate a little, maybe Walter is reading. ;-)

You know, I made that comment sortof as a stream-of-consciousness aside.  But your
suggestion made me think a little harder about it, because the kind of type
information that Eclipse builds for languages like Java would require quite a
trick to pull off in D.

Basically, Eclipse knows about every symbol and every class as you develop as you
type them (in Java).  It can do symbol typeahead suggestions, realtime reporting
of syntax and missing symbol errors, automatic suggestions for error quick fixes,
etc.  It has panels that can show you complete type hierarchies of anything in the
workspace, and these hierarchies will rearrange themselves in realtime as you make
changes to the classes they are displaying.  It has refactorings where you can
push down and pull up classes, rename symbols globally, etc.

Eclipse can do all that because it is constantly compiling java code that you
enter and then inspecting the types and/or analyzing the compilation errors it gets.

For something like that to be possible with D, we'd need a couple things.  One is
full reflection, where you can ask the runtime to give you a Class object for a
given type's name and look at it's full hierarchy and query that Class's fields,
methods, relationships, and dependencies.  In terms of tooling for some
super-dynamic environment like Eclipse, I think you'd almost have to have the
ability to build each and every class as a DLL on the fly and load it.  And the
DLL loaded would have to init in some sort of "Class metadata only mode" where
statics would not init on load - Eclipse would be loading the DLL only to get
access to the Class objects themselves, not to actually run any code.

Upon loading the class's DLL, the D runtime should be able to dynamically
reconfigure it's internal type database so that Class queries will return correct
type hierarchy information as the runtime understands that information now.
Eclipse could direct the D runtime to unload class DLL's as well - and it would do
this constantly as classes the user edits would be constantly recompiled in the
background.

I feel like the compiler for D would need to be intimately woven into the D
runtime to achieve this kind of tooling.  The compiler would need to be able to
compile a class, while incorporating all symbol information currently present and
loaded in the system.  The compiler would have to have a runtime interface that
could convert a D class file to a DLL and report on the names of the classes that
were just built.  Eclipse's tooling seems to take this instant compilation a step
further: and if there are any bugs in the code that gets compiled, its Java
compiler places UnresolvedCompilationError exceptions at the spot where each bug
is located.  This way, Eclipse's in-editor type system always has a valid class
file to load and reflect upon.

I think when the D runtime is running in "tool mode" it won't be very fast, but
with some creative behind-the-scenes work in the D runtime, you could have a D
program operate very dynamically.  Class DLL's could be loaded and unloaded and be
reflected upon as easily as classes in statically linked libraries are.

If D had this kind of robust type reflection and tool support, developing
low-level systems programs and games would be truly incredible.  I could see
plugins and addons for D for Eclipse sprouting up everywhere.  The refactorings
for D's advanced features would probably change how I write programs.

--Dave