Compiler patch for runtime reflection

Vladimir Panteleev vladimir at thecybershadow.net
Sun Oct 23 11:13:42 PDT 2011


On Sun, 23 Oct 2011 18:20:32 +0300, Alex Rønne Petersen  
<xtzgzorex at gmail.com> wrote:

> On 23-10-2011 14:51, Vladimir Panteleev wrote:
>> On Sun, 23 Oct 2011 14:06:42 +0300, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>>
>>>> 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.
>>>>
>>>
>>> The module can generate RTTI for all types recursively from the
>>> starting point iff that information is statically available. It does
>>> not have to be. A module that comes as .di + static library binary
>>> could return a reference to a private class that has a publicly
>>> exported base class. How would you generate RTTI for a statically
>>> invisible class?
>>
>> The only way to prevent such problems is to have RTTI generated by the
>> compiler and enabled always or by default.
>>
>> However, is such functionality even desirable? It is equivalent to
>> having a back door for accessing private class members (implementation
>> details in general).
>>
>
> Isn't that technically already possible by doing enough cast and pointer  
> arithmetic hacks? I don't think it really makes a difference. If someone  
> really wants to backdoor a type, they will find a way to do it.

Yes, but that's neither "safe" nor an actual language feature. Allowing  
RTTI to do the same would be both: my point was whether there should be a  
language feature for this (exploring unexposed types).

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


More information about the Digitalmars-d mailing list