Compiler patch for runtime reflection

[Robert Jacques]

On Tue, 25 Oct 2011 07:30:04 -0400, Gor Gyolchanyan <gor.f.gyolchanyan at gmail.com> wrote:
> You can always write @noreflect: at the start of your module and it
> will work as expected. what's the problem with that?
> Also, compiler would be able to automatically add that attribute to
> any symbol, which is private and does not escape the module.
> Again, not including reflection is purely _optimization_ issue and
> should not be interfered with it's functionality.
> Reflection is something you rarely have in mind when designing, for
> example, classes.
> Requiring explicit request for reflection defeats the purpose.
>
> You could just as well say "writing public on every member is a
> clutter". It is, but you don't have to do it to achieve the same
> effect.

You can always write @reflect: at the start of your module and will work as expected. what's the problem with that?

Rhetoric aside, Timon wasn't referring to code clutter on behalf of the programmer. He was referring to code bloat in the compiled program. The two are very different things.

Also, just because reflection is something you rarely have in mind when designing, doesn't mean it shouldn't be part of the design API. Reflection is somewhat equivalent to the extern protection modifiers and so should warren careful consideration. Furthermore, bugs with reflection, say due to a change in the API, don't break during compilation; they break at runtime. And practically, there's a decent change your customer, not your test suite, is going to find it.