inconsistent compile-time reflection

[deadalnix]

Le 09/05/2012 12:13, Gor Gyolchanyan a écrit :
> If this was brought up before, sorry for spamming.
>
> I've been working on dynamic memory structuring mechanism (run-time
> struct types) and I've felt the need to "import" the structure for a
> dynamic struct type from a static (regular D) struct type.
> When I was iterating over the members using __traits(allMembers,
> StructType) it successfully went through all members, but when (in
> case of a data field) I queried the type and address of the member
> using __traits(getMember, structInstance_, memberName) it displayed an
> error about the member not being defined. I figured out, that it was
> because of the member being private. Therefore, I have 2 questions:
>
> 1. If the __traits(getMember, ...) won't return private members, why
> does __traits(allMembers, ...) show them?
> 2. Why doesn't __traits(getMember, ...) return the private member in
> the first place? One could easily hack around this limitation by
> having the member analysis in a mixin template, so the analysis ends
> up in the same module, hence giving access to the private members.
> This doesn't provide any safety - only removes syntax sugar.
>
> There are numerous cases, where private members need to be accessed
> (serialization, for instance), wouldn't it be better to
> __traits(getProtection, ...) in cases, where protection needs to be
> respected?
> After all, it's not in the D's philosophy to restrict people from
> doing things "for their own good", like java does (that's why I hate
> java). A back door for those, who know what they're doing is always
> needed.
>

It has been raised, and this is a +1 for me.