Compiler patch for runtime reflection

Vladimir Panteleev vladimir at thecybershadow.net
Sun Oct 23 03:19:15 PDT 2011


On Sun, 23 Oct 2011 01:54:52 +0300, Alex Rønne Petersen  
<xtzgzorex at gmail.com> wrote:

> On 22-10-2011 17:18, Vladimir Panteleev wrote:
>> On Sat, 22 Oct 2011 16:35:57 +0300, Alex Rønne Petersen
>> <xtzgzorex at gmail.com> wrote:
>>
>>> On 22-10-2011 15:20, Andrej Mitrovic wrote:
>>>> On 10/22/11, Vladimir Panteleev<vladimir at thecybershadow.net> wrote:
>>>>> On Sat, 22 Oct 2011 13:50:32 +0300, Alex Rønne Petersen
>>>>> <xtzgzorex at gmail.com> wrote:
>>>>>
>>>>>> You could just introduce a -reflection switch to include reflection
>>>>>> information.
>>>>>
>>>>> As I mentioned in the previous thread on the subject, I think that
>>>>> ideally
>>>>> we should improve compile-time reflection so it's possible to  
>>>>> generate
>>>>> runtime reflection information at compilation time. Something like
>>>>> this:
>>>>>
>>>>> import reflection;
>>>>>
>>>>> enum reflectionForStdStdio =  
>>>>> generateReflectionForModule("std.stdio");
>>>>>
>>>>> void main()
>>>>> {
>>>>> reflectionForStdStdio.callFunction("writeln", "Hello, world!");
>>>>> }
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Vladimir mailto:vladimir at thecybershadow.net
>>>>>
>>>>
>>>> I think user properties would be a perfect fit for this. :)
>>>>
>>>> @reflected
>>>> struct Foo {}
>>>
>>> The only downside with either approach
>>
>> What do you mean by "either approach"? Which is the other one?
>>
>
> @reflected and generateReflectionForModule.
>
> - Alex

I don't see how my generateReflectionForModule idea requires any  
modification of the reflected code. The module can generate RTTI for all  
types used recursively from the starting point. If more precision is  
needed, it can be specified as generateReflectionForModule/etc. parameters.

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net


More information about the Digitalmars-d mailing list