On Tue, 25 Oct 2011 07:30:04 -0400, Gor Gyolchanyan
<gor.f.gyolchan...@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.
