Compiler patch for runtime reflection

[deadalnix]

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 ?