Compiler patch for runtime reflection

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Tue Oct 25 08:31:18 PDT 2011


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 <sandford at jhu.edu> wrote:
> 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.
>


More information about the Digitalmars-d mailing list