On Sun, 23 Oct 2011 12:17:45 -0400, Alex Rønne Petersen <xtzgzo...@gmail.com>
wrote:
On 23-10-2011 18:03, Robert Jacques wrote:
On Sun, 23 Oct 2011 07:06:42 -0400, Timon Gehr <timon.g...@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.
