Requiring explicit request for reflection contradicts D's "safety first, performance second" policy. lack of reflection is a safety issue too, because you won't be able to do some checks.
On Tue, Oct 25, 2011 at 7:31 PM, Gor Gyolchanyan <gor.f.gyolchan...@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. > disabling reflection manually is an act of optimization purely. > Forgetting to disable the reflection can only lead to unnecessary data > being stored. > > The second scenario is much less error-prone. > yes, it _may_ lead to code bloat if you forget to disable it where it > is _absolutely positively unneeded_, but forgetting to enable it will > just make your code useless in many situations. > > On Tue, Oct 25, 2011 at 7:20 PM, Robert Jacques <sandf...@jhu.edu> wrote: >> 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. >> >