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. ;-)

> I am already thinking of porting my videogame code to D (since I'm
> using a replacement GC heap in my C++ code anyhow, not like D is going to perform
> any slower.)

I would love to hear how the porting went, how long it took, and any thoughts that you got doing it. Especially in view of you being pretty new to D while doing it.

> I am just really liking the D language, thank you Walter and whoever else is
> responsible for this!  :)

Join the club!

== Quote from Georg Wrede (georg@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

Dave Woldrich wrote:
> == Quote from Georg Wrede (georg@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.

I could be wrong, but my understanding is that Eclipse implements these features with direct editing of the code symbol tree and automatic incremental compilation, not from reflection. Java reflection is a runtime feature.

Regardless, I am in favor of some kind of reflection. Personally, I think reasonable means of accomplishing it would be through optional addition of compile-time information which when coupled with a library would allow for dynamic runtime features.

  Bradley

Bradley Smith wrote:

> 
> Dave Woldrich wrote:
>> == Quote from Georg Wrede (georg@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.
> 
> I could be wrong, but my understanding is that Eclipse implements these features with direct editing of the code symbol tree and automatic incremental compilation, not from reflection. Java reflection is a runtime feature.

Yes, the Descent Eclipse plugin has ported most of the DMD parser to be used in Eclipse, such that it can build it's own code tree necessary for this stuff to work. Reflection is not part of it.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango