Compiler patch for runtime reflection

[Steven Schveighoffer]

On Mon, 24 Oct 2011 11:18:34 -0400, deadalnix <deadalnix at gmail.com> wrote:

> Le 24/10/2011 16:20, Steven Schveighoffer a écrit :
>> 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
>
> Well, if the compile time reflection is good enough, you can do this  
> without any runtime reflexion support in the compiler, just using a lib.
>
> Why not support this option ?

As others have mentioned, there should be a standard way so we don't have  
conflicting ways that don't mix.

Plus, it seems logical tome since the compiler is generating *some* RTTI,  
it should generate *all* of it (when asked to do so).

-Steve