proper code introspection

[Jonathan M Davis]

On Monday, July 09, 2012 21:49:57 Gor Gyolchanyan wrote:
> On Mon, Jul 9, 2012 at 9:37 PM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:
> > On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> > > Currently, code introspection in D is way worse, then it should be. And
> > > this is true for both compile-time and run-time introspection.
> > > Moreover, the available stuff is bugged out in the most critical places.
> > > I'd like to hear what people think would be a better way to handle
> > > code introspection.
> > 
> > You mean reflection?
> > 
> > - Jonathan M Davis
> 
> I mean compile-time and run-time information like:
> * What are the types this one can implicitly/explicitly convert to/from?
> * What does this alias point to (variable/type/template/function)?
> * What is the protection of this alias?
> * What aliases does this one contain?
> * What are the instances of this template?
> * What are the available types (including/excluding template instances)?
> * What modules are being compiled and what modules do they import?
> * What packages are visible from the specified import paths?
> 
> This kind of information can allow enormously powerful libraries to be
> built. For instance python-style dynamic type subsystem, which flawlessly
> integrates with existing static type system, making D the first ever hybrid
> static-dynamic typed language. This will include making functions and
> templates dynamic:
> 
> - Templates transformed into partially dynamically-typed
> functions/classes or associative arrays (in case of template variables).
> - Function and template overloading make dynamic, creating
> multi-dispatch functions.

So, yes, you mean reflection. We have it available at compile time, and the 
number of things that you can determine have been slowly increasing. Runtime 
reflection can be built from compile-time reflection (I believe that some 
libraries already exist which do this), but it's not baked in like it is in 
Java or C#, because there's a cost associated with it, and we don't want an 
object to pay for it if it's not going to use it.

- Jonathan M Davis