Reflection

[pragma]

In article <du6vsh$1cep$1 at digitaldaemon.com>, Bruno Medeiros says...
>
>Ok, I know many people have asked about reflection before, and surely 
>everyone agrees it's a useful feature.
>So what I want to know is what are the issues and challenges to design 
>and implement such feature? Because now that I think of it, it seems to 
>me it would be quite easy to implement runtime reflection, at least for 
>field members of class objects. (method members have some problems, 
>because of D's limited type information about function types)
[...snip...]
>None of this seems to be hard or long to implement, so how about it? (I 
>know many details need to be fleshed out, but the base idea seems good)
>

This is as good as any of the other proposals for Reflection this NG has seen.
Given that, I don't think the problem has ever been with the design of any given
proposal over the other. :)

If I had to guess, the major reason that's holding this kind of thing back from
the D specification, is how to justify adding all of the reflection symbol data
into the executable/binary/whatever.  I've learned that it can take up a very
serious amount of space, most of which is usually wasted thanks to stuff that
never comes up. For example: you're not likely to attempt to serialze something
in the std.stdio namespace.

But I also think nobody would argue that runtime reflection is a tradeoff
between bloat and a whole range of algorithms that require it.  The problem lies
more on the side of systems programmers and folks who shouldn't have to contend
with such baggage.

IMO, the the best way towoard a reflection API would be the addition of a
compiler switch that toggles the existance of an internal symbol lookup table*.
This way *any* reflection API proposal, Typeinfo extensions included, would
simply be built on top of it; plus you get a nice low-level rendition (just the
table) to work with too.

Should the developer not want that bloat, they simply turn off the lookup
generation, which lets the respective D reflection code simply fall flat on its
face (symbol searches and lookups will simply return nothing, or throw).  This
way, you can shift D toward whatever development mode you have in mind, just
like we do now with other constructs.

(*Alternatively, this could be done via code introspection much like how
inlining works - but its just nicer to be in charge of what gets added and what
gets tossed out)

- EricAnderton at yahoo