Compiler patch for runtime reflection

[Robert Jacques]

On Sun, 23 Oct 2011 12:17:45 -0400, Alex Rønne Petersen <xtzgzorex at gmail.com> wrote:
> On 23-10-2011 18:03, Robert Jacques wrote:
>> On Sun, 23 Oct 2011 07:06:42 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>> [snip]
>>> 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?
>>
>> You're not supposed to be able to. Runtime reflection should only apply
>> to public data members.
>
> I don't think that's necessarily a good idea. If you're doing something
> related to e.g. serialization and a type uses properties to hide fields
> (say, because the properties have in/out contracts), you would be unable
> to take those into account.

A serialized message is part of the public API of your program. It is exposed not only internally, but also to all those who interact with you. This includes malicious hackers; one only has to take a look at the history of JSON parses to see how serialization can be exploited on the web. Exposing private members publicly is an extremely unsafe operation and a violation of programmer intent; it should never be done auto-magically. If a type with private members wants to support serialization, it can add the appropriate custom routines and data verification checks to itself. If fact, it would seriously behoove us, if our serialization library defaulted to requiring that a custom validation check be run by each variable or one of its parents.