Reflection

[Bruno Medeiros]

pragma wrote:
> 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

With the RTTI info we already have, I don't think reflection would be 
that much more information. (especially if we don't put reflection info 
about the member's names).
But you are right, there should be eventually an option to control 
whether this info is added or not. If I'm not mistaken, most C++ 
compilers have options like this, with regards to C++ RTTI.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."