Compiler patch for runtime reflection

Steven Schveighoffer schveiguy at yahoo.com
Mon Oct 24 07:20:25 PDT 2011


On Fri, 21 Oct 2011 23:48:51 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

> On Fri, 21 Oct 2011 17:23:17 -0400, Daniel Gibson  
> <metalcaedes at gmail.com> wrote:
>> Am 21.10.2011 21:07, schrieb Vladimir Panteleev:
>>> Hi,
>>>
>>> Igor Stepanov has created a patch for DMD and Druntime which adds RTTI
>>> information for class and struct members.
>>>
>>> Example:
>>>
>>> import std.stdio;
>>>
>>> class Foo
>>> {
>>> static void PrintHello()
>>> {
>>> writeln("Hello");
>>> }
>>> }
>>> void main()
>>> {
>>> auto info = cast(OffsetTypeInfo_StaticMethod)Foo.classinfo.m_offTi[0];
>>> assert(info.name == "PrintHello");
>>> auto print = cast(void function())info.pointer;
>>> print(); //prints "Hello"
>>> }
>>>
>>> While the inclusion of such functionality into the language remains a
>>> disputed matter, would anyone be interested in an unofficial patch for
>>> this?
>>>
>>> Walter: would it be okay if the compiler changes were published as a
>>> GitHub fork, or should we stick to patches?
>>>
>>
>> I'd love to see proper runtime reflection support in D, including
>> functionality to get information about available methods (their name and
>> parameters) and a way to call them.
>
> What do you mean by their 'parameters'? What about overloads?  
> Attributes? Arguments? Argument attributes?
>
>> Something that is close to what Java offers would be great.
>
> And what, exactly does JAVA offer? What works? What doesn't work? What's  
> missing?
>
>> BTW: I don't really see the problem with providing this information
>> (overhead-wise) - the information needs to be available once per
>> class/struct, but objects of classes just need one pointer to it (other
>> types don't even need that because they're not polymorphic and - like
>> methods of structs - the address of the information is known at
>> compile-time).
>
> 1) Unused information is simply bloat: it increases exe size, slows the  
> exe down and increases the runtime memory footprint.
> 2) On a lot of systems (i.e. consoles, embedded, smart phones, tablets)  
> memory and disk space are both highly constrained resources that you  
> don't want to waste.
> 3) RTTI provides a back-door into a code-base; one that for many reasons  
> you may want to keep closed.

I agree to all these points.  I think runtime reflection should be  
generated by the compiler as needed.  And the mechanism to determine "as  
needed" should be an attribute IMO, or an intrinsic function (i.e. if you  
have all the static information about a type, you should be able to  
generate the RTTI for it).  I do not want programs getting bigger than  
they already are for the sake of "just in case I want to use reflection"...

-Steve


More information about the Digitalmars-d mailing list