Compiler patch for runtime reflection

[Robert Jacques]

On Tue, 25 Oct 2011 11:31:18 -0400, Gor Gyolchanyan <gor.f.gyolchanyan at gmail.com> wrote:
> As i said before, enabling reflection manually is an act of enabling a
> certain range of stuff you can do with the code. Forgetting to enable
> reflection can lead to serious problems, when the reflection is
> required.

And when, precisely, is reflection _required_? Granted, in other languages it is the only tool for the job. But we have a very big toolkit in D, and so far, I have yet to see any example (including Rails) which _requires_ the holistic runtime reflection proposed in these threads.

> disabling reflection manually is an act of optimization purely.

No, it isn't. Go read the rest of these threads for counter-arguments. Or the Java Best Practices guide. Or search the Open Web Application Security Project for reflection vulnerabilities.

> Forgetting to disable the reflection can only lead to unnecessary data
> being stored.

Alternatively, sensitive information being exposed.

> The second scenario is much less error-prone.

Incorrect, the second scenario is a security hole waiting to be exploited.

> yes, it _may_ lead to code bloat if you forget to disable it where it
> is _absolutely positively unneeded_,

Having written a (limited) runtime reflection library for D, yes it causes bloat even if you only enable it where _absolutely positively needed_.

> but forgetting to enable it will
> just make your code useless in many situations.

Correction: it will make code designed to _require_ runtime-reflection incompatible with code not designed to support reflection. Given the percentage of code that requires reflection (very small) and the percentage of code which wouldn't be compatible or trivially made to be compatible, (very small) I'm fine with that.